Method of processing traffic information and digital broadcast system

ABSTRACT

A digital broadcast transmitting/receiving system and a method for processing data are disclosed. The method for processing data may enhance the receiving performance of the receiving system by performing additional coding and multiplexing processes on the traffic information data and transmitting the processed data. Thus, robustness is provided to the traffic information data, thereby enabling the data to respond strongly against the channel environment which is always under constant and vast change.

This application claims the benefit of the Korean Patent ApplicationNos. 10-2005-0093639 filed on Oct. 5, 2005, 10-2006-0039117 filed onApr. 29, 2006, 10-2006-0089736 filed on Sep. 15, 2006 and10-2005-0097452 filed on Oct. 17, 2005, which is hereby incorporated byreference as if fully set forth herein. This application also claims thebenefit of the International Patent Application No. PCT/KR2006/002068filed on May 30, 2006, which is hereby incorporated by reference as iffully set forth herein.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to a digital broadcasting system, and moreparticularly, to a digital broadcast transmitting/receiving system and amethod for processing traffic data.

2. Discussion of the Related Art

Presently, the technology for processing digital signals is beingdeveloped at a vast rate, and, as a larger number of the population usesthe Internet, digital electric appliances, computers, and the Internetare being integrated. Therefore, in order to meet with the variousrequirements of the users, a system that can add video/audio datathrough a digital broadcasting (or television) channel so as to transmitdiverse supplemental information needs to be developed.

Some users may assume that supplemental data broadcasting would beapplied by using a PC card or a portable device having a simple in-doorantenna attached thereto. However, when used indoors, the intensity ofthe signals may decrease due to a blockage caused by the walls ordisturbance caused by approaching or proximate mobile objects.Accordingly, the performance of the received digital signals may bedeteriorated due to a ghost effect and noise caused by reflected waves.Therefore, a system highly resistant to (or robust against) ghosteffects and noise is required to be developed. Particularly, in orderfor the supplemental data to be used in portable and mobile broadcastreceivers, a higher degree of resistance (or robustness) against channelinterruption and noise is required.

The supplemental data are generally transmitted by a time-divisionmethod through the same channel as the MPEG video/audio data. However,with the advent of digital broadcasting, ATSC VSB digital televisionreceivers that receive only MPEG video/audio data are already suppliedto the market. Therefore, the supplemental data that are transmittedthrough the same channel as the MPEG video/audio data should notinfluence the conventional ATSC VSB receivers that are provided in themarket. In other words, this may be defined as ATSC VSB compatibility,and the supplemental data broadcast system should be compatible with theATSC VSB system. Herein, the supplemental data may also be referred toas enhanced data or EVSB data. Furthermore, as the number of possessedautomobiles (or cars) is in constant increase, and with the influence ofthe working-5-days-a-week policy (which eventually leads to an increasein the usage of cars), the need for traffic information is alsoincreasing accordingly.

SUMMARY OF THE INVENTION

Accordingly, the present invention is directed to a digital broadcasttransmitting/receiving system and a method for processing data thatsubstantially obviate one or more problems due to limitations anddisadvantages of the related art.

An object of the present invention is to provide a digital broadcastsystem and a method for processing data that can be compatible to theATSC VSB system, that is suitable for transmitting enhanced data, andthat is resistant to and robust against noise.

Another object of the present invention is to provide a digitalbroadcast transmitting/receiving system and a method for processing datathat can effectively receive and transmit traffic information byapplying the traffic information data as the enhanced data.

Another object of the present invention is to provide a digitalbroadcast transmitting/receiving system and a method for processing datathat can enhance the receiving performance of the receiving system byperforming additional coding on the traffic information data andtransmitting the processed data.

A further object of the present invention is to provide a digitalbroadcast transmitting/receiving system and a method for processing datathat can enhance the receiving performance of the receiving system bymultiplexing the known data, which correspond to data known in advanceaccording to an agreement between the transmitting system and thereceiving system, and the traffic information data.

Additional advantages, objects, and features of the invention will beset forth in part in the description which follows and in part willbecome apparent to those having ordinary skill in the art uponexamination of the following or may be learned from practice of theinvention. The objectives and other advantages of the invention may berealized and attained by the structure particularly pointed out in thewritten description and claims hereof as well as the appended drawings.

To achieve these objects and other advantages and in accordance with thepurpose of the invention, as embodied and broadly described herein, adigital broadcast transmitter according to an embodiment of the presentinvention may include a traffic information message generator, apre-processor, a multiplexer, a trellis encoder, and a transmitter.

The traffic information message generator may generate a trafficinformation message including status information, which includesinformation on at least one of an average speed of a traffic route androute travel time, and location information associated with the statusinformation. The pre-processor may pre-process traffic information dataincluding the traffic information message by encoding the trafficinformation data and by generating a traffic information data packetincluding the encoded traffic information data and known data. Themultiplexer may multiplex the traffic information data packet with oneor more main audio and video (AV) data packets. The trellis encoder mayhave at least one memory and trellis-encoding the multiplexed datapackets, the at least one memory being initialized by initializationdata when data outputted from the multiplexer correspond to a beginningof a known data sequence. The data transmission unit may insertsynchronization data into the trellis-encoded data, modulating thetrellis-encoded data having the synchronization data, and transmittingthe modulated data.

In other aspect of the present invention, a digital broadcasttransmitter may include a traffic information message generator, apre-processor, a multiplexer, a post-processor, a data encoding andinterleaving unit, a trellis encoder, and a transmitter.

The traffic information message generator may generate a trafficinformation message including status information, which includesinformation on at least one of an average speed of a traffic route androute travel time, and location information associated with the statusinformation. The pre-processor may pro-process traffic information dataincluding the traffic information message by encoding the trafficinformation data for at least one of error correction and errordetection and by generating a traffic information data packet includingthe encoded traffic information data and known data. The multiplexer maymultiplex the traffic information data packet with one or more mainaudio and video (AV) data packets. The post-processor post-processingthe multiplexed data by encoding only traffic information data includedin the multiplexed data with a coding rate of G/H, wherein G and H arepositive integers and G is less than H. The data encoding andinterleaving unit may add first parity data into the post-processed dataand interleave the post-processed data having the first parity data. Thetrellis encoder may have at least one memory and trellis-encoding theinterleaved data, the at least one memory being initialized byinitialization data when data outputted from the data encoding andinterleaving unit correspond to a beginning of a known data sequence.The data transmission unit may insert synchronization data into thetrellis-encoded data, modulating the trellis-encoded data having thesynchronization data, and transmitting the modulated data.

In another aspect of the present invention, a digital broadcasttransmitter may include a traffic information message generator, apre-processor, a multiplexer, a data encoding and interleaving unit, apost-processor, a trellis encoder, and a transmitter.

The traffic information message generator may generate a trafficinformation message including status information, which includesinformation on at least one of an average speed of a traffic route androute travel time, and location information associated with the statusinformation. The pre-processor may pre-process traffic information dataincluding a traffic information message by encoding the trafficinformation data for at least one of error correction and errordetection and by generating a traffic information data packet includingthe encoded traffic information data and known data. The multiplexer maymultiplex the traffic information data packet with one or more mainaudio and video (AV) data packets. The data encoding and interleavingunit may add first parity data into the multiplexed data and interleavethe multiplexed data having the parity data. The post-processor maypost-process the interleaved data by coding only traffic informationdata included in the interleaved data with a coding rate of G/H, whereinG and H are positive integers and G is less than H. The trellis encoderhaving at least one memory and trellis-encoding the post-processed data,the at least one memory being initialized by initialization data whendata outputted from the post-processor correspond to a beginning of aknown data sequence. The data transmission unit may insertsynchronization data into the trellis-encoded data, modulating thetrellis-encoded data having the synchronization data, and thetransmitting the modulated data.

In another aspect of the present invention, a method of processingtraffic data in a digital transmitter may include generating a trafficinformation message including status information, which includesinformation on at least one of an average speed of a traffic route androute travel time, and location information associated with the statusinformation, generating at least one system information table requiredfor decoding the traffic information message, and multiplexing thetraffic information message and the system information table.

In another aspect of the present invention, a digital broadcasttransmitter may include a traffic information message generator, asystem information generator, and a multiplexer.

The traffic information message generator may generate a trafficinformation message including status information, which includesinformation on at least one of an average speed of a traffic route androute travel time, and location information associated with the statusinformation. The system information generator may generate systeminformation required for decoding a traffic information message. Themultiplexer may multiplex the traffic information message and the systeminformation.

In another aspect of the present invention, a data structure may includesystem information required for decoding a traffic information messageincluding a traffic information message including status information,which includes information on at least one of an average speed of atraffic route and route travel time, and location information associatedwith the status information, the system information comprising a trafficinformation table which includes at least one of a traffic informationapplication identifier, a service component identifier, and serviceinformation.

In another aspect of the present invention, a method of processingtraffic information data in a digital broadcast receiver may includereceiving traffic information data including a traffic informationmessage and system information, demultiplexing the traffic informationmessage and the system information from the traffic information data,and decoding the traffic information message using the systeminformation, thereby extracting status information, which includesinformation on at least one of an average speed of a traffic route androute travel time, and location information associated with the statusinformation.

In a further aspect of the present invention, a digital broadcastreceiver may include a demodulator, a data demultiplexing and decodingunit, a data storage, and an application manager.

The demodulator may demodulate traffic information data including atraffic information message and system information and performing errorcorrection to the demodulated data. The data demultiplexing and decodingunit may demultiplex the traffic information message and systeminformation from the error-corrected data and decode the demultiplexedtraffic information message using the system information. The datastorage may store the system information and the decoded trafficinformation message. The application manager may provide a trafficinformation service to a user using the stored traffic informationmessage by extracting status information, which includes information onat least one of an average speed of a traffic route and route traveltime, and location information associated with the status information.

It is to be understood that both the foregoing general description andthe following detailed description of the present invention areexemplary and explanatory and are intended to provide furtherexplanation of the invention as claimed.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are included to provide a furtherunderstanding of the invention and are incorporated in and constitute apart of this application, illustrate embodiments of the invention andtogether with the description serve to explain the principle of theinvention. In the drawings:

FIG. 1 illustrates a transmission format of traffic informationaccording to the present invention;

FIG. 2 illustrates a structure of congestion and travel time informationincluded in a CTT event container;

FIGS. 3A through 3C illustrate average speed on a link, travel time forthe link, and syntax for degree of congestion included in the statuscomponent of the CTT event container of FIG. 2;

FIGS. 4A through 4C illustrate structures of a status componentdelivering average speed on a link;

FIGS. 5A through 5E illustrate information structures for travel timefor a link;

FIG. 6 illustrates a block view showing a general structure of a digitalbroadcast transmitting system according to an embodiment of the present;

FIG. 7 illustrates a syntax structure of traffic information descriptorsaccording to an embodiment of the present invention;

FIG. 8 illustrates an example of table that may include the trafficinformation descriptors of FIG. 7;

FIG. 9 illustrates a syntax structure on a virtual channel table whereinthe traffic information descriptors of FIG. 7 are included according toan embodiment of the present invention;

FIG. 10 illustrates a block view showing a structure of a digitalbroadcast transmitting system according to a first embodiment of thepresent invention;

FIG. 11 illustrates an example of a detailed block view showing an E-VSBpre-processor of FIG. 10;

FIG. 12A and FIG. 12B each illustrates a data structure before and aftera data deinterleaver of FIG. 10, respectively;

FIG. 13 illustrates a block view showing a structure of a digitalbroadcast transmitting system according to a second embodiment of thepresent invention;

FIG. 14 illustrates an example of a detailed block view showing an E-VSBpre-processor of FIG. 13;

FIG. 15 illustrates an example of a detailed block view showing an E-VSBpost-processor of FIG. 13;

FIG. 16 illustrates a block view showing a structure of a digitalbroadcast transmitting system according to a third embodiment of thepresent invention;

FIG. 17 illustrates a block view of a digital broadcast receiving systemaccording to an embodiment of the present invention;

FIG. 18 illustrates process steps of receiving traffic information dataaccording to an embodiment of the present invention;

FIG. 19 illustrates a detailed view of a demodulator of FIG. 17according to a first embodiment of the present invention; and

FIG. 20 illustrates a detailed view of a demodulator of FIG. 17according to a second embodiment of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

Reference will now be made in detail to the preferred embodiments of thepresent invention, examples of which are illustrated in the accompanyingdrawings. Wherever possible, the same reference numbers will be usedthroughout the drawings to refer to the same or like parts. In addition,although the terms used in the present invention are selected fromgenerally known and used terms, some of the terms mentioned in thedescription of the present invention have been selected by the applicantat his or her discretion, the detailed meanings of which are describedin relevant parts of the description herein. Furthermore, it is requiredthat the present invention is understood, not simply by the actual termsused but by the meaning of each term lying within.

In the present invention, the known data refer to a set of data known inadvance according to an agreement between a transmitting system and areceiving system. The main data refer to a set of data that can bereceived by a conventional receiving system. Both known data and maindata may include video data and/or audio data. Also, in the presentinvention, the enhanced data may refer to data including information,such as a program execution file, stock information, trafficinformation, and so on. The enhanced data may also include video dataand/or audio data. Such enhanced data may include traffic information,data for providing data service, system information for ground (orterrestrial) wave broadcasting such as PSI and/or PSIP, systeminformation for cable broadcasting such as out of band systeminformation (OOB-SI), supplemental data configured of diverse Javalanguage or HTML language for data services providing a wide range ofapplications, audio data, and video data. The enhanced data may alsoinclude various control software for controlling the receiver, and metadata that are configured of an XML language, for example, in order toprovide diverse information to the user.

In the description of the present invention, traffic information datawill be applied for the enhanced data, so as to be transmitted andreceived. A road searching service and a traffic information providingservice according to the present invention may be applied to a varietyof digital broadcast standards. Representative examples of the digitalbroadcast standards are a European Digital Audio Broadcasting (DAB)service based on the Eureka-147 [ETSI EN 300 401], a Digital VideoBroadcasting-Terrestrial (DVB-T) service provided in Europe, a DigitalVideo Broadcasting-Handheld (DVB-H) service also provided in Europe, aMedia Forward Link Only (FLO) service provided in the United States, anda Digital Multimedia Broadcasting (DMB) service that is provided in theRepublic of Korea. The DMB service of the Republic of Korea isclassified into a Terrestrial Digital Multimedia Broadcasting (T-DMB)service based on the Eureka-147 and a Satellite Digital MultimediaBroadcasting (S-DMB) service using satellite communication.

Herein, the traffic information includes information on publictransportation, congestion and/or travel time, road traffic, emergencyevents and situation, and so on. The traffic information also includesinformation associated with all types of transportation means includingtrain, ship (or cruiser), airplane, and so on. Furthermore, the trafficinformation may also include information on factors that may influencetraffic, such as travel information, information parking facilities,weather information, environmental pollution information, and so on.Most particularly, although the congestion and/or travel time(hereinafter referred to as “CTT”) information is given as an example ofthe present invention, any other information type may be applied herein.Furthermore, as long as the term indicates a particular function, theterms used; in the present invention are not limited only to the onesused in the description set forth herein.

The term “traffic status” is indicative of a road congestion status(i.e., a flow status), however, it is not limited to the above-mentionedroad congestion status and can be applied to similar examples asnecessary. For the convenience of description and better understandingof the present invention, the term “traffic status” is referred to as aCongestion and/or Travel Time Information (CTT) status. Theabove-mentioned CTT status includes CTT status information, and CTTstatus prediction information, additional information, and so on. Theterm “section” or “link” is indicative of a specific area of roads.However, it is not limited to the above-mentioned meanings and may beapplied to other similar meanings as necessary.

The traffic information service according to the present invention isprovided to the users by a receiver having only one or none of anelectronic map and a GPS mounted therein in the form of at least one ofa text, a voice, a graphic, a still image, and a motion picture. Thetraffic information data are configured and transmitted by trafficinformation message units. More specifically, the traffic informationmessage is the smallest unit for transmitting the traffic information.Herein, information on a single traffic information application isincluded in a traffic information message. In the present invention, theterm “Transport Protocol Expert Group (TPEG)” will be used on thetraffic information for simplicity. Furthermore, as described above, aslong as the term indicates a particular function, the terms used in thepresent invention are not limited only to the ones used in thedescription set forth herein.

The traffic information application corresponds to the highest hierarchywithin an ISO/OSI protocol stack. Each traffic information applicationis assigned with a unique identification number, which is referred to asan application identification (AID). Each time a new application isdeveloped and created, a new application identification is assigned. Forexample, each of the congestion and/or travel time (CTT) information,the road traffic message (RTM), the public transport information (PTI),and so on, is a traffic information application that is given uniqueapplication identification. The traffic information data correspond to astream form including various traffic information messages. Herein, thetraffic information messages correspond to at least one application.

FIG. 1 illustrates an example of two traffic information applications(e.g., CTT and RTM) being included in a stream.

Traffic information message generator (not shown in figure) generating atraffic information message can be a broadcast station. For simplicityof the description of the present invention, the traffic informationmessage generator is referred to as a traffic information providingserver. The traffic information message generator construct in a trafficinformation message unit traffic congestion information collected fromvarious sources (e.g., operator input, or information received fromanother server or probe cars through a network).

At this point, each traffic information message has the same containerconfiguration, which may be referred to as a traffic information (orTPEG) message container. The CTT message container described hereincorresponds to one of the traffic information message containers. Morespecifically, the CTT message container according to the presentinvention, which transmits the CTT message, includes a. CTT messagemanagement container 102, a CTT-status container 104, and aTPEG-location container 106.

The above-mentioned CTT message management container 102 includes amessage identification information and date and time information, anduses the message identification information and the date and timeinformation as management information of the information received by thereceiving system. The message ID information requisite for the messageincludes a message identifier (MID) and a version number (VER). In thiscase, the message ID (MID) is indicative of an identifier of a singlemessage associated with individual status of a service component. TheMID according to the present invention gradually increases the MIDnumber from 0 by a predetermined number “1” at a time. If the MID valuereaches the maximum value “65535”, the maximum value “65535” isinitialized to zero. The version number (VER) is indicative of asequential number for identifying successive messages having a singlemessage ID. The version number according to the present invention may bedetermined to be any one of 0 to 255, and it should be noted that theversion number is sequentially increased in the range from 0 to 255.

The CTT status container 104 may include congestion and/or travel timestatus and predicted congestion and travel time status of links, i.e.,road segments. The CTT status container 104 may include average linkspeed link travel time, link delay, or congestion type, etc.

The TPEG location container 106 may employ various location referenceprocesses. For example, a location reference process using a coordinatesystem or a location reference process using pre-promised links may beused. When a coordinate system is used, the coordinates (latitudes andlongitudes) of the start and end positions of a link for which the CTTmessage is created, may be transmitted. When a reference process usingpre-promised links is used, a unique identification for a specific linkon a receiving device may be transmitted. For example, a receivingdevice may include a locally stored network of links, wherein each linkmay be identified by a unique identifier. A link may refer to a roadsegment which starts and ends at junctions and has no junction inbetween. The coordinate system may be the WGS 84 model. A text formattedname of the link may be transmitted.

In various implementations, a CTT status container and a TPEG locationcontainer, are composed of one or more CTT components. A CTT statuscontainer 104 may be composed of one component or a plurality of CTTcomponents. In various implementations, CTT components including an IDof 80h (notation ‘h’ means hexadecimal) or 84h includes one or morestatus components including basic traffic information such as theaverage link speed, link travel time, link delay, or congestion type. Inthe description, specific IDs are described as assignments to structuresassociated with specific information. The actual value of an assigned ID(e.g., 80h) is exemplary, and different implementations may assigndifferent values for specific associations or circumstances.

In various implementations, CTT components including an ID of 81hinclude one or more status components including predicted CTT status.The predicted CTT status may include predicted average link speed,predicted link travel time, or congestion acceleration tendency. Thecongestion acceleration tendency may include information indicative ofthe tendency of congestion status. The congestion acceleration tendencywill be described as a type of prediction information as the congestionstatus in the near future may be predicted from it.

In various implementations, the CTT message may comprise CTT componentsstructured to deliver additional information of traffic information. Anidentifier 8Ah may be assigned to the CTT component carrying additionalinformation, and a language code that is indicative of language used forthe additional information may also be included in the CTT component.

FIG. 2 illustrates a syntax, according to various implementations, of astructure of a congestion and travel time information component(hereinafter, referred to as CTT component) belonging to a CTT eventcontainer (e.g., at reference numeral 22 for FIG. 2). The FIG. 2 CTTcomponent has an ID of ‘0x80’ 3 a, includes m status components 3 c, andhas a field expressed in byte 3 b indicating the length of the wholedata of the status components included therein.

Status components may, for example, use 8 bits to transfer average speedon a link, travel time for a link, and/or information about degree ofcongestion in a format illustrated in FIGS. 3A through 3C. In oneimplementation, an ID of ‘00’ is assigned to average speed on a link; anID of ‘01’ is assigned to travel time for a link; and an ID of ‘03’ isassigned to degree of congestion.

A numeric value expressed in units such as, for example, of 0.5 m/s(namely, 1.8 km/h) may be carried in the field 41 for average speed on alink (‘intunti’ denotes size of byte) and a numeric value expressed inunits such as, for example, minutes is carried in the field for traveltime for a link 42. Information about travel time for a link may beobtained by retrieving the link length from a link information (e.g.,link length, link width, etc.) database constructed in the server 100and dividing the link length by average speed on the corresponding linkobtained from traffic information collected from various sources, beingprovided after further rounding off to the units of minute (e.g., atravel time exceeding 30 seconds is rounded off to one minute).

In one implementation, if average speed on a link is transmitted in theunits of 0.5 m/s (1.8 km/h), the allowable range of the speed in 8-bitexpression may amount to 0˜459 km/h. Since it may be unnecessary toexpress the average speed up to a very high value (e.g., beyond 200km/h), it may be better to consider a very high speed (e.g., averagespeed higher than 200 km/h) to be resulting from drivers speeding in thecorresponding link rather than current traffic condition. Accordingly,from a viewpoint of providing traffic congestion information, it may beuseless to provide information indicating up to a very high speed.

On the other hand, in the case of traffic congestion, even 1 km/hdifference in the average speed may be an important factor for a driverto choose a particular route. In this respect, a resolution of 1.8 km/hcannot discriminate 1 km/h difference in the average speed. Therefore,when average speed on a link becomes low, the average speed informationexpressed in units of 0.5 m/s (=1.8 km/h) may not satisfy driversrequirement on the degree of resolution.

Similarly, if travel time for a link is provided in units of minute,round-off error may become large when the length of the link is short.For example, if the link length is 500 meters and average speed on thelink is 20 m/s (=72 km/h), travel time for the link will become 25seconds; if the link length is 1000 meters and average speed on the linkis 20 m/s, travel time for the link will become 50 seconds; for anotherexample, if the link length is 2900 meters and average speed on the linkis 20 m/s, travel time for the link will be 145 seconds. In these cases,the travel time for the link delivered to the status componentcorresponds to 0, 1, and 2 minutes, respectively; therefore, thedifference between actual travel time and the travel time provided bytraffic information amounts to 25, 10, and 25 seconds. These errors maybecome more prominent in links of short lengths.

Therefore, in various implementations, as to the delivery of informationabout average speed on a link, the maximum speed is lower than may beintroduced to improve resolution in low speed links. Likewise, as to thedelivery of information about travel time for a link, informationexpressed in units of seconds may be permitted an 8 bit representationmay be employed for delivering information about travel time for a linkexpressed in units of seconds; however, additional bits may also beassigned to deliver the information expressed in units second.

As shown in FIG. 4A, in one implementation, the following format fordelivering information about average speed on a link may be employed:0.25 m/s (=0.9 km/h). By using the speed unit, the maximum speed that an8-bit field indicative of average speed 51 may represent becomes 229.5km/h.

The unit of 0.25 m/s is only an arbitrary example; therefore, in orderto increase the speed resolution in a link of slow speed, a much lowerunit, for example, 0.2 m/s (the maximum allowable speed forrepresentation is 183.6 km/h) or 0.15 m/s (the maximum allowable speedfor representation is 137.7 km/h) may be employed. Increasing speedresolution by lowering the speed unit is advantageous for the caseswhere traffic regulations restrict the maximum speed (e.g., to 110km/h).

As shown in FIG. 4B, average speed on a link may also be provided inunits of 1 km/h. According to this implementation, the allowable rangethat the field indicative of average speed 52 may represent becomes0˜255 km/h and figures below a decimal point do not occur. Although themaximum speed allowable for representation is decreased in theimplementation of FIG. 4B compared with the example of FIG. 3A (459km/h→255 km/h), the speed resolution is improved by 0.8 km/h (1.8 km/h→1km/h).

The speed resolution may play an important role depending on themagnitude of the average speed on the current link. As describedearlier, when the average speed on a link is low, a driver may respondsensitively to a slight change of the average speed, whereas the drivermay show lower sensitivity against a slight change of the average speedif the average speed on the link is high. Therefore, in variousimplementations, a variable speed unit may be employed in accordancewith the magnitude of the average speed. FIG. 4C illustrates an exampleof a structure of the average speed field of a status componentaccording to one implementation. The most significant bit (F) designatesa speed unit on which the average speed represented by the remaining 7bits (Speed_Value) is based. For example, if the most significant bit(F) is 0, it implies that the value carried by the remaining 7 bits(Speed_Value) corresponds to the average speed expressed in units of 0.5km/h; when the most significant bit (F) is 1, the value carried by theremaining 7 bits (Speed_Value) corresponds to the average speedexpressed in units of 1 km/h.

In the implementation of FIG. 4C, since the maximum speed that may beexpressed in 0.5 km/h unit is 63.5 km/h (=127*0.5 km/h), when the mostsignificant bit (F) is 1, the average speed amounts to the sum of whatthe remaining 7 bits represent and 63.5 km/h. As to a high speed value,an integer value of 63 km/h may be added instead of 63.5 km/h. Forexample, if the average speed field is 1:0001100, the average speed tobe delivered will be 759.5 km/h (=12 km/h+63.5 km/h) or 759 km/h (=12km/h+63 km/h).

Specifying the speed resolution with the two different units of 0.5 km/hand 1 km/h in the implementation of FIG. 4C is only an example; adifferent resolution from the specified unit may be employed. Therefore,a variable resolution depending on the magnitude of the average speed ona link should be considered to fall within the scope, even though anemployed speed resolution may be different from what is described in thethis disclosure.

An implementation of a format delivering information about travel timefor a link is illustrated in FIGS. 5A through 5D.

In the implementation of FIG. 5A, the higher 5 bits of 8 bits arereserved for minutes and lower 3 bits 61 are reserved for seconds. Sincethe allowable range that the lower 3 bits can express is from 0 to 7,the lower 3 bits 61 records the value of tens of the element expressedin second from the travel time for a link. That is to say, from thethree examples described earlier, since the travel time for the link is25, 50, and 145 seconds (2 minutes and 25 seconds), the lower 3 bits 61records 3 (which corresponds to 30 - - - 5 seconds are rounded off), 5(which corresponds to 50), and 3 (which corresponds to 30); the higher 5bits records 0, 0, and 2, respectively. In the present implementation,respective errors become 5, 0, and 5 seconds and relative errormagnitudes are reduced to 20% (=5/25), 0% (=0/10), and 20% (=5/25),being reduced to 13.3% on the average compared with the case expressedin minute.

In the implementation of FIG. 5B, the time unit for the 8 bit expressionis varied as needed. More specifically, lower 7 bits are reserved torepresent travel time for a link in units of minute or second; the mostsignificant bit 62 is used as a flag to designate whether the contentrecorded in the 7 bits is measured in units of minute or second. Whenthe content is expressed in minute, 0 is assigned, whereas 1 is assignedwhen the content is expressed in second. Since the travel time for thelink is 25, 50, and 145 seconds from the previous three examples,10011001 (flag=1), 10110010 (flag=1), and 00000010 (flag=0) (=2 minutes)or 11111111 (flag=1) (=127 seconds) are recorded in the 8 bits,respectively. In the present implementation, respective errors become 0,0, and 25 seconds (or 18 seconds) and relative error magnitudes are 0%,0%, and 100% (or 72%), being reduced to 33.3% (or 24%) on the averagecompared with the case expressed in minute.

In the implementation of FIG. 5C, the entire 8 bits are used to recordtravel time for a link, the recording unit being less than 60 secondsand larger than 1 second (e.g., 10 seconds). Since the travel time forthe link is 25, 50, and 145 seconds from the previous three examples, 3(5 seconds are rounded off), 5, and 15 are each recorded in the 8 bitsaccording to the implementation of FIG. 5C. In the presentimplementation, respective errors become 5, 0, and 5 seconds andrelative error magnitudes are 20%, 0%, and 20%, being reduced to 13.3%on the average compared with the case expressed in minute. Although thepresent implementation shows identical results to those from theimplementation of FIG. 5A, the maximum time allowable for expressingtravel time for a link is 2550 seconds (4 minutes and 30 seconds),thereby being larger than 31 minutes and 50 seconds of theimplementation of FIG. 5A.

Additional bits may be assigned through a mechanism such as that shownby FIG. 5D. FIG. 5D is an implementation where a flag of one bitdenoting time unit is appended.

In the implementation of FIG. 5D, the entire 8 bits are reserved fortravel time for a link and an additional one bit flag 63 (e.g., thisflag is set to 0 when the time unit corresponds to minute, whereas it is1 when the time unit is second) is so assigned as to specify whether thetime recorded in the 8 bits is expressed in minute or second. Since thetravel time for the link is 25, 50, and 15 seconds from the previousthree examples, 1:8 bits (flag: data) according to the implementation ofFIG. 5D holds 1:00011001, 1:00110010, and 1:10010001, respectively. Theerror from each case becomes 0 in the present implementation, the errorrate being reduced by 100% compared with the case expressed in minute.

When the additional one bit does not make up 8 bits in such a way thateffective information is carried in the other constituting 7 bits, the 7bits may be wasted for the sake of simplicity for informationprocessing. Therefore, when effective information is not included in theconstituting 7 bits and thus delivered to the status component (ID0x01), it may be useful to deliver the travel time for a link by 16 bitsrather than to additionally deliver the one bit flag only, as shown inFIG. 5E (‘intunli’ in FIG. 5E denotes size of 16 bits). In theimplementation of FIG. 5E, the entire 16 bits represent the travel timefor the link 64 expressed wholly in second. In the implementation ofFIG. 5E where the entire 16 bits are used to express travel time for alink, the maximum allowable time becomes 18 hours 12 minutes and 16seconds. This representation capacity can accommodate travel time for alink for nearly all links without error.

The implementations of FIGS. 5A through 5C, where travel time for a linkis expressed with 8 bits, have improved features compared with the casewhere the 8 bits are used to express the travel time for the link inunits of minute only. However, for the implementations of FIGS. 5A and5C, since the maximum allowable time for each case is 31 minutes and 50seconds; and 42 minutes and 30 seconds, respectively, if a part of thelink gets congested and travel time thus becomes elongated, a case whereinformation delivery fails may happen due to the inability to representthe travel time for the link. For the implementation of FIG. 5B, aproblem exists that as for the travel time for a link exceeding 127seconds, an error happens identically to the case where the travel timefor a link is delivered in units of minute. It may be particularlyadvantageous to employ the FIG. 5C-5E solutions when a larger range or amore precise range is required.

The above described traffic information data require a more stablereceiving performance than the general audio and/or video data, i.e.,the main data. In case of the main data, small errors that cannot benoticed by the eyes and ears of a user are not problematic. Conversely,in case of the traffic information data, even a 1-bit size error cancause a serious problem. Therefore, the traffic information data areprocessed with an additional coding process, which is then multiplexedwith the main data and transmitted. Thus, robustness is provided to thetraffic information data, such as the CTT data, thereby enabling thedata to respond strongly against the channel environment which is alwaysunder constant and vast change. At this point, system information isrequired in order to extract the traffic information data from thechannel through which the traffic information data are transmitted and,then, to decode the extracted traffic information data. In some cases,the system information is referred to as service information. The systeminformation may include channel information, event information, and soon.

In the preferred embodiment of the present invention, program specificinformation/program and system information protocol (PSI/PSIP) isapplied as the system information. However, the present invention is notlimited only to the example given in the description set forth herein.More specifically, if the system information corresponds to a protocolbeing transmitted in a table format may be applied to the presentinvention regardless of name of the system information. The PSI is anMPEG-2 system standard defined for classifying the channels and theprograms. And, PSIP is an advanced television systems committee (ATSC)standard having channels and programs that can be classified.

Herein, the PSI may include a program association table (PAT), aconditional access table (CAT), a program map table (PMT), and a networkinformation table (NIT). More specifically, the PAT corresponds to aspecial information that can be transmitted by a packet having a packetidentification (PID) of ‘0’. The PAT transmits the corresponding PIDinformation of the PMT and the corresponding PID information of the NITfor each program. The CAT transmits information on a paid broadcastsystem that is used by the transmitting end. The PMT transmits PIDinformation of a transport stream packet to which the programidentification number and separate bit sequences, such as video data andaudio data configuring the corresponding program, are transmitted. ThePMT also transmits PID information to which the PCR is transmitted. TheNIT transmits information of the actual transmission network.

On the other hand, the PISP may include a virtual channel table (VCT), asystem time table (STT), a rating region table (RRT), an extended texttable (ETT), a direct channel change table (DCCT), a direct channelchange selection code table (DCCSCT), an event information table (EIT),and a master guide table (MGT). The VCT transmits information on thevirtual channel such as channel information for selecting the channeland a packet identification (PID) for receiving audio data and/or videodata. More specifically, by parsing the VCT, PIDs of the audio data andvideo data corresponding to the broadcast program that is beingtransmitted through the channel along with the channel name, channelnumber, and so on. The STT transmits information on the current weatherand time, and the RRT transmits information on the region anddeliberation committee for program rating. The EIT transmits informationon the events of a virtual channel (e.g., program title, program starttime, etc.). The DCCT/DCCSCT transmits information associated withautomatic channel change, and the MGT transmits version and PIDinformation of each table within the PSIP.

Each table within the above-described PSI/PSIP includes a basic unitreferred to as a “section”, and at least one or more sections arecombined to configure a table. For example, the VCT may be divided into256 sections. Herein, a single section may carry a plurality of channelinformation. However, the information on the virtual channel is notdivided into two or more sections. An example of multiplexing andtransmitting a traffic information message and a table associated with asystem information is given in the description of the present invention.

FIG. 6 illustrates a block view showing a general structure of a digitalbroadcast transmitting system according to an embodiment of the present,wherein a traffic information message and a table associated with thesystem information are multiplexed and transmitted. Referring to FIG. 6,the transmitting system includes a first multiplexer 311, a PSI/PSIPgenerator 312, and a second multiplexer 313. More specifically, forexample, the transmitting system may correspond to a broadcast station.In order words, the traffic information message is inputted to the firstmultiplexer 311 in a 188-byte transport stream (TS) packet unit. Herein,the traffic information message a traffic information application (e.g.,a CTT application) that is to be transmitted.

The TS packet is configured of a header part and a payload part. Herein,the header part includes information indicating the beginning of thedata and packet identification (PID) identifying the data partcorresponding to the payload part. And, the payload part includes atraffic information message that is intended to be transmitted. At thispoint, the PID within the header part may either correspond to anidentifier that can identify the data carried by the payload part as thetraffic information message among the enhanced data, or correspond to anidentifier that can identify the enhanced data. In case the PID of theheader can identify the traffic information message, the trafficinformation message may be extracted from the TS packet. On the otherhand, in case the PID of the header can identify the enhanced data, allTS packets identified as the enhanced data are received. Thereafter, thetraffic information message is extracted from the received enhanceddata. Furthermore, the TS packet which carries the traffic informationmessage may correspond either to a packetized elementary stream (PES)type or to a section type. In other words, either a PES type trafficinformation message may be configured as the TS packet, or a sectiontype traffic information message may be configured as the TS packet.

An example of the traffic information message being transmitted as thesection type will be described in the present invention. In thisembodiment of the present invention, the traffic information message isincluded in a digital storage media-command and control (DSM-CC)section, and the DSM-CC section is then configured as a 188-byte size TSpacket. Herein, the identifier of the TS packet configuring the DSM-CCsection is included in a data service table (DST). When transmitting theDST table, ‘0x95’ is assigned as a stream_type field value within aservice location descriptor of either the PMT or the VCT. Morespecifically, in the receiving system, when the stream_type field valueof the PMT or VCT is equal to ‘0x95’, this indicates that databroadcasting (i.e., enhanced data) including the traffic informationdata is being received. At this point, the traffic information data maybe transmitted by a data carousel method. Herein, the data carouselmethod refers to repeatedly transmitting the same data periodically.

Meanwhile, the PSI/PSIP generator 312 is an example of a systeminformation generator. The table that may be created by the PSI is atleast one of PMT, PAT, CAT, and NIT. And, the table that may be createdby the PSIP is at least one of VCT, STT, RRT, ETT, DCCT, DCCST, EIT, andMGT. The table created by the PSI/PSIP generator 312 includes a systeminformation so that the receiving system may parse and decode thetraffic information message. At this point, the receiving system may useonly the tables within the PSI, or only the tables within the PSIP, or acombination of tables within both the PSI and the PSIP, so as to parseand decode the traffic information message. At least the PAT and PMT ofthe PSI and at least the VCT of the PSIP is required for parsing anddecoding the traffic information message. For example, the PAT mayinclude the system information transmitting the traffic informationmessage and the PID of the PMT corresponding to the traffic informationmessage (or program number). The PMT may include the PID of the TSpacket transmitting the traffic information message. The VCT may includethe PID of the TS packet transmitting the information of the virtualchannel, which transmits the traffic information message, and thetraffic information message.

Also, the present invention includes supplemental information associatedwith traffic information specifically indicating to which applicationthe traffic information message belonged and information specificallyindicating which information is included. The supplemental informationassociated with the traffic information may include service componentidentification information, application identification information,service information, and so on. The service information may includeservice name, service description, service logo, subscriber information,free text information, help information, and so on. Furthermore, suchsupplemental information may be included in a particular table withinthe PSI/PSIP either in a descriptor format or in a field format.

For simplicity of the description of the present invention, a descriptorincluding the supplemental information associated with the trafficinformation that is included in a particular table within the PSI/PSIPis referred to as a traffic information descriptor. Herein, the trafficinformation descriptor may also be referred to as a TPEG servicedescriptor. As described above, the term “traffic informationdescriptor” is only an example given to facilitate the understanding ofthe present invention. Therefore, any other term having the samefunction as the traffic information descriptor may also be appliedherein. Moreover, in the description of the present invention, theparticular table including the traffic information descriptor is definedas a traffic information providing table. Furthermore, the particulartable including the traffic information descriptor is defined as asystem information (SI) table wherein the traffic information descriptoris included.

FIG. 7 illustrates a syntax structure of traffic information descriptorsaccording to an embodiment of the present invention. Referring to FIG.7, the TPEG service descriptor may include a Descriptor_tag field, aDescriptor_length field, a Number_of_TPEG_Service_Components field, anda ‘for’ loop repetition statement. Herein, theNumber_of_TPEG_Service_Components field indicates the number of servicecomponents included in the TPEG service descriptor (or trafficinformation descriptor). And, the ‘for’ loop repetition statement isrepeated as much as the value of the Number_of_TPEG_Service_Componentsfield. The repetition statement may include a Service_Component_IDfield, an Application_ID field, and a service information field.

More specifically, the Descriptor_tag field is an 8-bit field, which isgiven a value that can uniquely identify the TPEG service descriptor. Inthe example of the present invention, a value of 0xAC is given as thetag value of the TPEG service descriptor. However, this is only anexample provided for an easier understanding of the present invention.Depending upon the design of the system designer, other kind of unusedtag values may be allocated to the Descriptor_tag field. TheDescriptor_length field is an 8-bit field, which indicates in byte unitsthe length starting from the Descriptor_length field to the end of thisfield.

The Service_component_ID (SCID) field is also an 8-bit field, whichindicates a value that can uniquely identify the service componentwithin a service. The SCID field may be decided by the service provider.Herein, a single service component substantially corresponds to a singlechannel within the TPEG stream. The Application_ID field is a 16-bitfield, which indicates a value that can uniquely identify eachapplication. More specifically, a unique application identifier (AID) isassigned to each traffic information application, and a new AID isallocated whenever a new application is developed (or created).

The service information field within the repetition statement mayinclude a Service_name field, a Service_description field, aService_logo field, a Subscriber_information field, aFree_text_information field, and a Help_information field. The length ofeach field within the service information field is variable and isindicates in the form of at least one of a text sequence, numbers, andgraphics. The Service_name field indicates the name of a service, whichallows the user to identify a particular service. For example, a servicename such as ‘TPEG service of broadcast company A’ may be included whenthe broadcast program is being transmitted. The Service_descriptionfield indicates a detailed description of the corresponding service.This field is for describing the service contents in more detail. Forexample, a service named “suburban public transportation information inthe southern urban area” may be included and transmitted. TheService_logo field indicates a service logo, so as to allow a service ora service provider to be identified visually. The service logo isgenerally transmitted in a bitmap format or any other image format.

The Subscriber_information field indicates the subscriber information.For example, information such as a user fee for limited (or restricted)service components and payment information may be included andtransmitted. The Free_text_information field indicates additionalinformation that is to be transmitted to the user. For example,information on an interruption (or suspension) of a service,cancellation of a particular information, and so on, may be included andtransmitted. And, the Help_information field indicates help informationwhich the user can refer to. For example, information such as Internetaddresses, telephone numbers, and so on may be included herein andtransmitted.

The order, location, and meaning of each field shown in FIG. 7 aremerely examples for facilitating the understanding of the presentinvention. And, since the order, location, and meaning of each field,and the number of field being additionally allocated can be adequatelymodified by anyone skilled in this field, the present invention is notlimited only to the examples set forth herein. Also, in the examplegiven in the present invention, the traffic information descriptor shownin FIG. 7 is included in at least one of the PMT of the PSI and the VCTof the PSIP and then transmitted.

More specifically, in the description of the present invention, anexample of applying the PMT of the PSI and the VCT of the PSIP as thetraffic information providing table. This indicates that thesupplemental information associated with the traffic information may betransmitted through the PMT and/or VCT of the descriptor or the field.Similarly, when supplemental information associated with the trafficinformation is described in a field format, it is apparent that thefields can be applied to at least one of the tables of the PMT of thePSI and the VCT of the PSIP. Herein, the process of including the PMTand/or the VCT in the traffic information descriptor may be eithermandatory or optional. Furthermore, whether the PMT and/or the VCTare/is mandatorily or optionally included is also merely an example ofthe present invention. Accordingly, the example does not limit the scopeand spirit of the present invention.

FIG. 8 illustrates an example of table that may include the trafficinformation descriptors of FIG. 7. More specifically, FIG. 8 showsexamples of the main descriptor types used in the PSI/PSIP table, thedescriptor tag values allocated to each descriptor, and the PSI/PSIPtables using at least one of the above-described descriptors. Referringto FIG. 8, a service location descriptor indicated as ‘S’ must alwaysexist in the VCT. More specifically, the service location descriptorcarries the audio PID and video PID of a broadcast program. Also, in acorresponding service each of the descriptors must be included in thetables indicated as ‘M (i.e., mandatory)’ and may or may not be includedin the tables indicated as ‘O (i.e., optionally)’.

For example, AC-3 audio descriptor is given a value of 0x81 as thedescriptor tag value and must indicate that it is used in the PMT andEIT. Furthermore, the TPEG service descriptor according to the exampleof the present invention is given a value of 0xAC the descriptor tagvalue and is marked as ‘mandatory (M)’ on the PMT and VCT. Theabove-described example is only proposed to simplify the description ofthe present invention. The TPEG service descriptor may also be marked as‘mandatory (M)’ or ‘optional (O)’ on at least one of the PMT and VCT.The 0xAC value given as the TPEG service descriptor tag value is alsoonly proposed as an example for facilitating the understanding of thepresent invention. Accordingly, depending upon the design of the systemdesigner, other unused tag values may also be assigned herein.

FIG. 9 illustrates a syntax structure on a virtual channel table (VCT)wherein the traffic information descriptors of FIG. 7 are includedaccording to an embodiment of the present invention. Herein, the syntaxstructure and its meaning correspond to those of a private section. TheVCT syntax of FIG. 9 is configured by including at least one of atable_id field, a section_syntax_indicator field, a private_indicatorfield, a section_length field, a transport_stream_id field, aversion_number field, a current_next indicator field, a section_numberfield, a last_section_number field, a protocol_version field, and anum_channels_in_section field.

The VCT syntax further includes a first ‘for’ loop repetition statementthat is repeated as much as the num_channels_in_section field value. Thefirst repetition statement may include at least one of a short_namefield, a major_channel_number field, a minor_channel_number field, amodulation_mode field, a carrier_frequency field, a channel_TSID field,a program_number field, an ETM_location field, an access_controlledfield, a hidden field, a service_type field, a source_id field, adescriptor_length field, and a second ‘for’ loop statement that isrepeated as much as the number of descriptors included in the firstrepetition statement. Herein, the second repetition statement will bereferred to as a first descriptor loop for simplicity. The descriptordescriptors( ) included in the first descriptor loop is separatelyapplied to each virtual channel.

Furthermore, the VCT syntax may further include anadditional_descriptor_length field, and a third ‘for’ loop statementthat is repeated as much as the number of descriptors additionally addedto the VCT. For simplicity of the description of the present invention,the third repetition statement will be referred to as a seconddescriptor loop. The descriptor additional_descriptors( ) included inthe second descriptor loop is commonly applied to all virtual channelsdescribed in the VCT.

As described above, referring to FIG. 7, the table_id field indicates aunique identifier (or identification) (ID) that can identify theinformation being transmitted to the table as the VCT. Morespecifically, the table_id field indicates a value informing that thetable corresponding to this section is a VCT. For example, a 0xC8 valuemay be given to the table_id field.

The version_number field indicates the version number of the VCT. Thesection_number field indicates the number of this section. Thelast_section_number field indicates the number of the last section of acomplete VCT. And, the num_channel_in_section field designates thenumber of the overall virtual channel existing within the VCT section.Furthermore, in the first ‘for’ loop repetition statement, theshort_name field indicates the name of a virtual channel. Themajor_channel_number field indicates a ‘major’ channel number associatedwith the virtual channel defined within the first repetition statement,and the minor_channel_number field indicates a ‘minor’ channel number.More specifically, each of the channel numbers should be connected tothe major and minor channel numbers, and the major and minor channelnumbers are used as user reference numbers for the corresponding virtualchannel.

A virtual channel number is assigned to the traffic information messageaccording to the present invention, and the traffic information messagemay be transmitted through the assigned virtual channel. In this case,the short_name field indicates the name of the virtual channel throughwhich the traffic information message is transmitted. Themajor_channel_number/minor_channel_number field the number of thevirtual channel through which the traffic information message istransmitted. The program_number field is shown for connecting thevirtual channel having an MPEG-2 program association table (PAT) andprogram map table (PMT) defined therein, and the program_number fieldmatches the program number within the PAT/PMT. Herein, the PAT describesthe elements of a program corresponding to each program number, and thePAT indicates the PID of a transport packet transmitting the PMT. ThePMT described subordinate information, and a PID list of the transportpacket through which a program identification number and a separate bitsequence, such as video and/or audio data configuring the program, arebeing transmitted.

The source_id field indicates a program source connected to thecorresponding virtual channel. Herein, a “source” refers a particularsource such as a video image, data or sound. The value of the source_idfield corresponds to a unique value within the transport stream, whichtransmits the VCT. In an example according to the present invention, thetraffic information descriptor describing the supplemental informationassociated with traffic information (i.e., supplemental informationassociated with the CTT) is included in the first descriptor loop. Asdescribed above in the description of the VCT, it is apparent thatanyone skilled in the art can apply the example given in the presentinvention to other tables.

According to the present invention, there are two different methods ofdefining the PID of the VCT, which includes the traffic informationdescriptor. Herein, the PID of the VCT is a packet identifier (PID)required for identifying (or distinguishing) the VCT from the othertables. In the first method, the PID of the VCT according to the presentinvention may be set to depend upon the MGT. In this case, the receivingsystem cannot directly identify (or verify) the plurality of tables ofthe PSIP or PSI. Therefore, the VCT can be read only after the PIDdefined by the MGT is checked. Herein, the MGT is a table defining thePID, size, version number, and so on, of the plurality of tables. In thesecond method, the PID of the VCT according to the present invention maybe set to have a base PID value (i.e., a fixed PID value) that isindependent from the MGT. Unlike the first method, the second method ismore advantageous in that the VCT can be identified without having toverify every single PID of the MGT. Evidently, the agreement on the basePID should precede the transmitting system and the receiving system.

As described above, the PAT, PMT, VCT, MGT, DCCT, and so on, describingthe system information and supplemental information associated withtraffic information are generated by the PSI/PSIP generator 312. Herein,the PMT is provided to the first multiplexer 311, and the remainingtables excluding the PMT (i.e., PAT, VCT, MGT, DCCT, and so on) areprovided to the second multiplexer 313. The first multiplexer 311multiplexes the traffic information message, which includes informationon the traffic information application that is to be transmitted (e.g.,CTT application), with the PMT, which is generated from the PSI/PSIPgenerator 312, to a 188-byte transport stream (TS) packet. Thereafter,the multiplexed message and table are outputted to the secondmultiplexer 313. The second multiplexer 313 multiplexes the output ofthe first multiplexer 311 with the tables outputted from the PSI/PSIPgenerator 312 to a 188-byte transport stream (TS) packet. Subsequently,the multiplexed message and table are outputted for additional coding.

An example of providing the PMT to the first multiplexer 311 andproviding the remaining tables to the second multiplexer 313 is proposedin the description of the present invention. However, the presentinvention may also be designed to have a single multiplexer byintegrating the first multiplexer 311 and the second multiplexer 313.The traffic information data that are outputted from the multiplexer ofFIG. 6 for additional coding include a traffic information message andPSI/PSIP tables associated with the traffic information messagemultiplexed therein. Also, at least one of the above-described tables(e.g., PMT, VCT) may include a traffic information descriptor shown inFIG. 7.

Hereinafter, the coding and transmitting processes of the trafficinformation data will be described in detail according to first, second,and third embodiments of the present invention. By performing theadditional coding process on the traffic information data, robustnesscan be provided to the traffic information data, such as the CTT data.Thus, the data can respond swiftly and appropriately to the channelenvironment that undergoes fast and frequent change.

FIRST EMBODIMENT

FIG. 10 illustrates a block view showing a structure of a digitalbroadcast transmitting system according to a first embodiment of thepresent invention. Referring to FIG. 10, the digital broadcasttransmitting system includes an E-VSB pre-processor 401, a packetmultiplexer 402, a data randomizer 403, a RS encoder 404, a datainterleaver 405, a backward compatibility processor 406, a trellisencoder 407, a frame multiplexer 408, a pilot inserter 409, a VSBmodulator 410, and a RF up-converter 411. Herein, as shown in FIG. 11,the E-VSB pre-processor 401 includes an E-VSB randomizer 421, a RS frameencoder 422, an E-VSB block processor 423, a group formatter 424, a datadeinterleaver 425, and a packet formatter 426.

In the digital broadcast transmitting system having the above describedstructure, the main data are inputted to the packet multiplexer 402. Onthe other hand, the traffic information data are inputted to the E-VSBpre-processor 401, which performs additional coding processes so as toenable the traffic information data to respond quickly with robustnessagainst noise and channel change. The E-VSB randomizer 421 of the E-VSBpre-processor 401 receives the traffic information data, therebyrandomizing the received data and outputting the randomized data to theRS frame encoder 422. Herein, since the E-VSB randomizer 421 randomizesthe traffic information data, the randomizing process of data randomizer403 on the traffic information in a later process may be omitted.

The RS frame encoder 422 receives the randomized traffic informationdata and performs at least one of an error correction coding process andan error detection coding process on the received data. Accordingly, byproviding robustness to the traffic information data, the data canscatter group error that may occur due to a change in the frequencyenvironment. Thus, the data can respond appropriately to the frequencyenvironment which is very poor and liable to change. The RS framemultiplexer 422 also includes a process of mixing in row units many setsof traffic information data each having pre-determined size. Byperforming an error correction coding process on the inputted trafficinformation data, the RS frame encoder 422 adds data required for theerror correction and, then, performs an error detection coding process,thereby adding data required for the error detection process.

The error correction coding uses the RS coding method, and the errordetection coding uses the cyclic redundancy check (CRC) coding method.When performing the RS coding process, parity data required for errorcorrection are generated. And, when performing the CRC coding process,CRC data required for error detection are generated. More specifically,the RS frame encoder 422 identifies the traffic information data byunits of a predetermined length (A). Then, a plurality of (A)-lengthunits of traffic information data is grouped so as to form (orconfigure) a RS frame. Thereafter, an RS coding process is performed inat least one of a row direction and a column direction on the newlyconfigured RS frame. In the present invention, the predetermined lengthunit (A) corresponds to 187 bytes.

If the inputted traffic information data correspond to a 188-byte unitMPEG transport stream (TS) packet, the first MPEG synchronization byteis removed, so as to form a 187-byte unit packet. Herein, the MPEGsynchronization byte is removed because all traffic information datapackets are given the same value. The MPEG synchronization byte may alsobe removed during the randomizing process on the E-VSB randomizer 421.In this case, the process of removing the MPEG synchronization byteperformed by the RS frame encoder 422 is omitted. More specifically, ifthe inputted traffic information data does not include a fixed byte thatcan be removed, or if the length of the inputted packet is not 187bytes, the inputted traffic information data is distinguished by187-byte units. Thereafter, a plurality of 187-byte units of trafficinformation data is grouped so as to form (or configure) a RS frame.Thereafter, an RS coding process is performed in at least one of a rowdirection and a column direction on the newly configured RS frame.

Depending upon the channel situation between the transmission and thereception, an error may be included in the RS frame. When such erroroccurs, the CRC data (or CRC code or CRC checksum) may be used forchecking whether an error exists by each row unit. In order to generate(or create) the CRC checksum, the RS frame encoder 422 performs CRCcoding on the RS-coded traffic information data. The CRC checksumcreated by the CRC coding process may be used for notifying whether adamage has occurred by an error while the traffic information data arebeing transmitted through a channel. In the present invention, errordetection coding method other than the CRC coding method may be used.Alternatively, an error correction coding method may be used in order toenhance the overall error correction ability of the receiving end.

The traffic information data sets RS-coded and CRC-coded, as describedabove, are outputted to the E-VSB block processor 423. The E-VSB blockprocessor 423 codes the RS-coded and CRC-coded traffic information dataat a coding rate of G/H (wherein G and H are integers, and G<H) and thenoutputs the G/H-rate coded data to the group formatter 424. For example,if 1 bit of the input data is coded to 2 bits and outputted, then G isequal to 1 and H is equal to 2 (i.e., G=1 and H=2). Alternatively, if 1bit of the input data is coded to 4 bits and outputted, then G is equalto 1 and H is equal to 4 (i.e., G=1 and H=4).

An example performing a coding process at a coding rate of ½ (alsoreferred to as a ½-rate coding process) or a coding process at a codingrate of ¼ (also referred to as a ¼-rate coding process) on the trafficinformation data is given in the description of the present invention.More specifically, in case of performing the ½-rate coding process, theE-VSB block processor 423 receives 1 bit and codes the received 1 bit to2 bits (i.e., 1 symbol). Then, the E-VSB block processor 423 outputs theprocessed 2 bits (or 1 symbol). On the other hand, in case of performingthe ¼-rate coding process, the E-VSB block processor 423 receives 1 bitand codes the received 1 bit to 4 bits (i.e., 2 symbols). Then, theE-VSB block processor 423 outputs the processed 4 bits (or 2 symbols).At this point, in case of performing the ¼-rate coding process, thesymbol coded at a ½ coding rate may be repeated twice so as to output 2symbols, or the input data may be coded twice at a ½ coding rate so asto output 2 symbols.

The ¼-rate coding process may provide more enhanced error correctionability, due to the higher coding rate as compared to the ½-rate codingprocess. For this reason, the data coded at a ¼ coding rate by the groupformatter 424 in a later process are allocated to locations (orpositions) in which the channel may affect the performance. On the otherhand, the data coded at a ½ coding rate are allocated to locationshaving better performance. Thus, a difference in performance may bedecreased. The above-mentioned ½-coding rate and ¼-coding rate are onlyexemplary embodiments proposed in the description of the presentinvention, and the coding rate may vary depending upon either theselection of the coded symbols or the number of repetition.

The group formatter 424 inserts the traffic information data outputtedfrom the E-VSB block processor 423 in a corresponding area within a datagroup formed according to a pre-defined rule. Also, the group formatter424 inserts various place holders related to data interleaving or knowndata sets to a corresponding area within the data group. At this point,the data group may be described by at least one hierarchical area. And,depending upon the characteristic of each hierarchical area, the datatype being allocated to each area may also vary.

FIG. 12A illustrates a data structure of data groups prior to the datadeinterleaving process, and FIG. 12B illustrates a data structure ofdata groups after the data deinterleaving process. FIG. 12A illustratesan example of a data group within a data structure prior to the datadeinterleaving, the data group being divided into three hierarchicalareas: a head area, a body area, and a tail area. Accordingly, in thedata group that is inputted for the data deinterleaving process, dataare first inputted to the head area, then inputted to the body area, andinputted finally to the tail area. The three areas described above areonly exemplary to facilitate the understanding of the present invention.Depending upon the design of the system designer, the areas may bedescribed in a smaller number of areas or a larger number of areas.Further, the data being inserted in each area may also vary. Therefore,the present invention is not limited only to the example proposedherein.

As described above, the head, body, and tail areas have been given as anexample to simplify the description of the present invention.Additionally, in the example shown in FIG. 12A, the data group is set tohave head, body, and tail areas so that the body area is defined as thearea which is not mixed with the main data area within the data group.The data group is divided into a plurality of areas so that each areamay be used differently. More specifically, the area that is notinterfered by the main data has a highly resistant receiving performanceas compared to the area that is interfered by the main data.Furthermore, when using a system inserting and transmitting the knowndata to the data group, and when a long and continuous set of known datais to be inserted periodically in the enhanced data, a predeterminedlength of known data may be periodically inserted in the body area.However, since the main data may be mixed in the head and tail areas, itis difficult to periodically insert the known data, and it is alsodifficult to insert a long and continuous set of known data.

Assuming that the data group is allocated to a plurality of hierarchicalareas, as shown in FIG. 12A, the above-described E-VSB block processor423 may code the data that are to be inserted in each area, according tothe characteristic of each hierarchical area, at different coding rates.In the example of the present invention, the receiving system usesdifferent coding rates based on areas in which it is assumed thatperformance may vary after performing an equalization process usingchannel information that may be used for channel equalization.

For example, the traffic information data that are to be inserted in thebody area are ½-rate coded by the E-VSB block processor 423, and such½-rate coded traffic information data are inserted to the body area bythe group formatter 424. Additionally, the traffic information data thatare to be inserted in the head and tail areas are ¼-rate coded by theE-VSB block processor 423. Herein, the ¼-rate coding provides greatererror correction performance as compared to ½-rate coding. Thereafter,¼-rate coded traffic information data are inserted to the head and tailareas by the group formatter 424. Alternatively, the traffic informationdata that are to be inserted in the head and tail areas may be coded bythe E-VSB block processor 423 at a coding rate providing more efficienterror correction performance. Subsequently, such coded trafficinformation data are inserted in the head and tail areas by the E-VSBblock processor 423, or such coded data may be stored in a reserve areafor future usage.

As shown in FIG. 12A, apart from the traffic information data coded andoutputted from the E-VSB block processor 423, the group formatter 424also inserts an MPEG header place holder, a non-systematic RS parityplace holder, and a main data place holder in relation with the datadeinterleaving. Referring to FIG. 12A, the main data place is allocatedbecause the traffic information data and the main data are alternatelymixed in the head and tail areas based upon the input of the datadeinterleaver. In the output data that have been data deinterleaved, theplace holder for the MPEG header is allocated to the very beginning ofeach packet.

The group formatter 424 either inserts the known data generated by apre-decided method in a corresponding area, or inserts a known dataplace holder in a corresponding area so as to insert the known data in alater process. Moreover, a place holder for initializing the trellisencoder 407 is inserted in the corresponding area. For example, theinitialization data place holder may be inserted in front of the knowndata sequence. The output of the group formatter 424 is inputted to thedata interleaver 425. The data deinterleaver 425 performs an inverseprocess of the data interleaver on the data within the data group andthe place holder outputted from the group formatter 424. And, then, thedata deinterleaver 425 outputs the deinterleaved data to the packetformatter 426. More specifically, when the data within the data groupand the place holder the configuration shown in FIG. 12A aredeinterleaved by the data deinterleaver 425, the data group beingoutputted to the packet formatter 426 has the structure (orconfiguration) shown in FIG. 12B.

Among the deinterleaved and inputted data, the packet formatter 426removes the main data place holder and the RS parity place holder thathave been allocated for the deinterleaving process. Then, the packetformatter 426 groups the remaining portion of the input data and insertsthe remaining data to the 4-byte MPEG header place holder in the MPEGheader. Furthermore, when the known data place holder is inserted by thegroup formatter 424, the packet formatter 426 may insert the known datain the known data place holder. Alternatively, the known data placeholder may be directly outputted without any modification for thereplacement insertion in a later process.

Thereafter, the packet formatter 426 configures the data within the datagroup packet that is formatted as described above, as a 188-byte unittraffic information data packet. Then, the packet formatter 426 providesthe configured 188-byte unit traffic information data packet to thepacket multiplexer 402. The packet multiplexer 402 multiplexes the188-byte traffic information data packet and the main data packetoutputted from the packet formatter 426 according to a pre-definedmultiplexing method. Then, the multiplexed packets are outputted to thedata randomizer 403. The multiplexing method may be altered or modifiedby various factors in the design of the system.

In a multiplexing method of the packet multiplexer 402, a trafficinformation data burst section and a main data section are distinguished(or identified) along a time axis, then the two sections are set to berepeated alternately. At this point, in the traffic information databurst section, at least one of the data groups may be transmitted, andonly the main data may be transmitted in the main data section. In thetraffic information data burst section, the main data may also betransmitted. When the traffic information data are transmitted in theabove-described burst structure, the digital broadcast receiving systemreceiving only the traffic information data may turn on the power onlyduring the data burst section. Alternatively, in the main data sectionwhereby only the main data are transmitted, the power is turned offduring the main data section, thereby preventing the main data frombeing received. Thus, excessive power consumption of the digitalbroadcast receiving system may be reduced or prevented. As describedabove, the packet multiplexer 402 receives the main data packet and thedata group, which is outputted from the packet formatter 426, andtransmits the received packets in a burst structure.

When the inputted data correspond to the main data packet, the datarandomizer 403 performs a randomizing process identical to that of theconventional randomizer. More specifically, the MPEG synchronizationbyte within the main data packet is discarded (or deleted). Then, theremaining 187 bytes are randomized by using a pseudo random bytegenerated from within the data randomizer 403. Subsequently, therandomized data bytes are outputted to the RS encoder 404.

However, when the inputted data correspond to the traffic informationdata packet, the MPEG synchronization byte among the 4 bytes inserted inthe traffic information data packet by the packet formatter 426 isdiscarded (or deleted) and only the remaining 3 bytes are randomized.The remaining portion of the traffic information data excluding the MPEGheader is not randomized and outputted directly to the RS encoder 404.This is because a randomizing process has already been performed on thetraffic information data by the E-VSB randomizer 421. The RS encoder 404RS-codes the data randomized by the data randomizer 403 or the databypassing the data randomizer 403. Then, the RS encoder 404 adds a20-byte RS parity to the coded data, thereby outputting theRS-parity-added data to the data interleaver 405.

At this point, if the inputted data correspond to the main data packet,the RS encoder 404 performs a systematic RS-coding process identical tothat of the conventional ATSC VSB system on the inputted data, therebyadding the 20-byte RS parity at the end of the 187-byte data.Alternatively, if the inputted data correspond to the trafficinformation data packet, each place of the 20 parity bytes is decidedwithin the packet. Thereafter, the 20 bytes of RS parity gained byperforming the non-systematic RS-coding are respectively inserted in thedecided parity byte places. The data interleaver 405 receives the datahaving the parity added by the RS encoder 404 and interleaves thereceived data. Thereafter, the data interleaver 405 outputs theinterleaved data to the backward compatibility processor 406 and thetrellis encoder 407. Herein, the data interleaver 405 corresponds to abyte unit convolutional interleaver.

Meanwhile, a memory within the trellis encoder 407 should first beinitialized in order to allow the output data of the trellis encoder 407so as to become the known data defined based upon an agreement betweenthe receiver and the transmitter. More specifically, the memory of thetrellis encoder 407 should first be initialized before the known datasequence being inputted is trellis-encoded. At this point, the beginningof the known data sequence that is inputted corresponds to theinitialization data place holder inserted by the group formatter 424 andnot the actual known data. Therefore, a process of generatinginitialization data right before the trellis-encoding of the known datasequence being inputted and a process of replacing the initializationdata place holder of the corresponding trellis encoder memory with thenewly generated initialization data are required. This is to ensure thebackward-compatibility with the conventional receiving system.

The trellis memory initialization data generated to replace theinitialization data place holder are decided based upon the currentstatus of the memory within the trellis encoder 407 and the desiredinitialization status. Further, due to the replaced initialization data,a process of recalculating the RS parity of the corresponding datapacket and a process of replacing the newly calculated RS parity withthe RS parity outputted from the data interleaver 405 are required.Therefore, the backward compatibility processor 406 receives the trafficinformation data packet including the initialization data place holderthat is to be replaced with the initialization data from the datainterleaver.

Subsequently, the backward compatibility processor 406 receives theinitialization data from the trellis encoder 407. Then, the backwardcompatibility processor 406 calculates a new non-systematic RS parityand outputs the newly calculated non-systematic RS parity to the trellisencoder 407. Thereafter, the trellis encoder 405 selects the output ofthe data interleaver 405 as the data within the traffic information datapacket including the initialization data place holder that is to bereplaced. The trellis encoder 405 also selects the output of thebackward compatibility processor 406. Accordingly, the trellis encoder405 trellis-encodes the selected outputs by symbol units. Morespecifically, the trellis encoder 407 trellis-encodes the initializationdata instead of the initialization data place holder included in thetraffic information data packet which has been inputted.

Meanwhile, when the main data packet is inputted or when the trafficinformation data packet is inputted, wherein the traffic informationdata packet does not include the initialization data place holder thatis to be replaced, the trellis encoder 407 selects the data outputtedfrom the data interleaver 405 and the RS parity, thereby performing atrellis-encoding process by symbol units. Then, the data trellis-encodedby the trellis encoder 407 are inputted to the frame multiplexer 408.The frame multiplexer 408 inserts field and segment synchronizationsignals in the output of the trellis encoder 407 and outputs theprocessed data to the pilot inserter 409. The pilot inserter 409 adds apilot signal to the output symbol sequence of the frame multiplexer 408.The pilot-added symbol sequence is modulated to a 8VSB signal of anintermediate frequency band and, then, converted to a RF band signal,thereby being transmitted through the antenna.

Meanwhile, the embodiment shown in FIG. 11 for the components andpositioning of the components of the E-VSB pre-processor 401 is merelyan example for the simplicity of the description of the presentinvention. According to a second embodiment of the present invention,the E-VSB pre-processor 401 includes a RS frame encoder, an E-VSBrandomizer, an E-VSB block processor, a group formatter, a datainterleaver, and a packet formatter. The difference between the secondembodiment and the E-VSB pre-processor shown in FIG. 11 is thepositioning order of the RS frame multiplexer and the E-VSB randomizer.More specifically, in the second embodiment of the present invention, RSframe coding is first performed on the traffic information data, andthen the data randomizing process is performed. Apart from this detail,the remaining structure of the second embodiment is identical to theembodiment shown in FIG. 11. Therefore, a detailed description of thesame will be omitted for simplicity.

In a third embodiment of the present invention, the E-VSB pre-processor401 includes a RS frame encoder, an E-VSB randomizer, a group formatter,an E-VSB block processor, a data interleaver, and a packet formatter.The difference between the third embodiment and the E-VSB pre-processorshown in FIG. 11 is the positioning order of the RS frame multiplexerand the E-VSB randomizer and, also, the positioning order of the groupformatter and the E-VSB block processor. More specifically, in E-VSBpre-processor according to the third embodiment of the presentinvention, RS frame coding is first performed on the traffic informationdata, and then the data randomizing and byte expansion processes areperformed. Thereafter, group formatting, E-VSB block processing, datarandomizing, and packet formatting processes are sequentially performedon the byte-expanded traffic information data.

In this case, since the group formatter is positioned before the E-VSBblock processor, a byte expansion process needs to be performed beforethe group formatter in order to correspond to the coding process of theE-VSB block processor, thereby enabling the group formatter to operatewithout trouble. Therefore, the E-VSB randomizer not only randomizes thetraffic information data but also performs byte expansion by insertingnull data bits. Furthermore, the E-VSB block processor performs one of a½-rate coding process and a ¼-rate coding process on only the valid dataof the byte-expanded traffic information data, which correspond to thedata bits having the actual information. As described above, the E-VSBpre-processor 401 performing additional coding processes on the trafficinformation data may be applied in various methods. Thus, the presentinvention is not limited only to the examples given in the descriptionset forth herein.

SECOND EMBODIMENT

FIG. 13 illustrates a block view showing a structure of a digitalbroadcast transmitting system according to a second embodiment of thepresent invention. Referring to FIG. 13, the digital broadcasttransmitting system includes an E-VSB pre-processor 501, a packetmultiplexer 502, a data randomizer 503, an E-VSB post-processor 504, aRS encoder 505, a data interleaver 506, a backward compatibilityprocessor 507, a trellis encoder 508, a frame multiplexer 509, a pilotinserter 510, a VSB modulator 511, and a RF up-converter 512. Herein, asshown in FIG. 14, the E-VSB pre-processor 501 includes a RS frameencoder 521, an E-VSB randomizer 522, a group formatter 523, a datadeinterleaver 524, and a packet formatter 525. Further, as shown in FIG.15, the E-VSB post-processor 504 includes RS parity place holderinserter 531, data interleaver 532, an E-VSB block processor 533, datadeinterleaver 534, and a RS parity place holder remover 535.

In the digital broadcast transmitting system according to the secondembodiment of the present invention having the above describedstructure, the main data are inputted to the packet multiplexer 502. Onthe other hand, the traffic information data are inputted to the E-VSBpre-processor 501, which performs additional coding processes so as toenable the traffic information data to respond quickly with robustnessagainst noise and channel change.

The RS frame encoder 521 of the E-VSB pre-processor 501 receives therandomized traffic information data and performs at least one of anerror correction coding process and an error detection coding process onthe received data. Accordingly, by providing robustness to the trafficinformation data, the data can scatter group error that may occur due toa change in the frequency environment. Thus, the data can respondappropriately to the frequency environment which is very poor and liableto change. The RS frame multiplexer 521 also includes a process ofmixing in row units many sets of traffic information data each havingpre-determined size. The error correction coding uses the RS codingmethod, and the error detection coding uses the cyclic redundancy check(CRC) coding method. When performing the RS coding process, parity datarequired for error correction are generated. And, when performing theCRC coding process, CRC data required for error detection are generated.

In the RS frame encoder 521, the process of creating the RS framecreating process and the process of performing error correction codingand error detection coding on the created RS frame are identical tothose of the RS frame encoder 422 shown in FIG. 11. Therefore, adetailed description of the same will be omitted for simplicity. Thetraffic information data coded by the RS frame encoder 521 are inputtedto the E-VSB randomizer/byte expander 522. The E-VSB randomizer/byteexpander 522 receives the coded traffic information data and performsdata randomizing and byte expansion processes thereon.

At this point, since the E-VSB randomizer/byte expander 522 alreadyperforms a randomizing process on the traffic information data, theprocess of randomizing the traffic information by the data randomizer503 at a later end may be omitted for simplicity. Further, the order ofperforming the data randomizing process and the byte expansion processmay be altered. More specifically, the byte expansion process may beperformed after the data randomizing process. Alternatively, the datarandomizing process may be performed after the byte expansion process.The order may be selected while taking into consideration the overallsystem and its structure.

The byte expansion may differ depending upon the coding rate of theE-VSB block processor 533 within the E-VSB post-processor 504. Morespecifically, when the coding rate of E-VSB block processor 533 is G/H,the byte expander expands G bytes to H bytes (wherein G and H areintegers, and G<H). For example, if the coding rate if ½, 1 data byte isexpanded to 2 data bytes. Alternatively, if the coding rate if ¼, 1 databyte is expanded to 4 data bytes. Then, the traffic information dataoutputted from the E-VSB randomizer/byte expander 522 is inputted to thegroup formatter 523. The operations of the group formatter 523, datadeinterleaver 524, and the packet formatter 525 within the E-VSBpre-processor 501 are similar to those the group formatter 424, datadeinterleaver 425, and the packet formatter 426 within the E-VSBpre-processor 401 shown in FIG. 10. Therefore, a detailed description ofthe same will be omitted for simplicity.

The traffic information data packet pre-processed by the E-VSBpre-processor 501 is inputted to the packet multiplexer 502 so as to bemultiplexed with the main data packet. The data multiplexed andoutputted from the packet multiplexer 502 are data randomized by thedata randomizer 503 and, then, inputted to the E-VSB post-processor 504.Herein, the operations of the packet multiplexer 502 and data randomizer503 are identical to those shown in FIG. 10, and therefore a detaileddescription of the same will be omitted for simplicity. Hereinafter, theE-VSB post-processor 504 will now be described in detail.

More specifically, the data randomized by the data randomizer 503 orbypassing the data randomizer 503 are inputted the RS parity placeholder inserter 531 of the E-VSB post-processor 504. When the inputteddata correspond to a 187-byte main data packet, the RS parity placeholder inserter 531 inserts a 20-byte RS parity place holder at the backof the 187-byte data, thereby outputting the processed data to the datainterleaver 532. Alternatively, when the inputted data correspond to a187-byte traffic information data packet, the RS parity place holderinserter 531 inserts a 20-byte RS parity place holder within the datapacket in order to perform a non-systematic RS-coding process in a laterend. Thereafter, in the remaining portion of the 187 byte places bytesare inserted in the traffic information data packet, which are thenoutputted to the data interleaver 532.

The data interleaver 532 performs a data interleaving process on theoutput of the RS parity place holder inserter 531 and, then, outputs theprocessed data to the E-VSB block processor 533. The E-VSB blockprocessor 533 performs additional coding processes on the valid dataamong the traffic information data being outputted from data interleaver532. For example, if 1 byte has been expanded to 2 bytes by insertingnull bits between data bits from the E-VSB randomizer/byte expander 522,the E-VSB block processor 533 ½-rate codes only the valid data bit amongthe symbol configured of a null bit and a valid data bit and, then,outputs the processed data. On the other hand, if 1 byte has beenexpanded to 4 bytes by inserting null bits between data bits from theE-VSB randomizer/byte expander 522, the E-VSB block processor 533 ¼-ratecodes only the valid data bit among the symbol configured of 3 null bitsand 1 valid data bit and, then, outputs the processed data.

Either the main data or the RS parity place holder directly bypasses theE-VSB randomizer/byte expander 522. Also, the known data and theinitialization data place holder may directly bypass the E-VSBrandomizer/byte expander 522. In case of the known data place holder,the known data generated from the E-VSB block processor 533 may beoutputted instead of the known data place holder. The data being coded,replaced, and bypassed from the E-VSB block processor 533 are inputtedto the data deinterleaver 534. The data deinterleaver 534 performs aninverse process of the data interleaver 532, whereby a datadeinterleaving process is performed on the input data, which are thenoutputted to the RS parity place holder remover 535.

The RS parity place holder remover 535 removes the 20-byte RS parityplace holder inserted by the RS parity place holder inserter 531 for theoperations of the data interleaver 532 and the data deinterleaver 534and, then, outputs the processed data to the RS encoder 505. At thispoint, if the inputted data correspond to main data packet, the last 20bytes of RS parity place holders are removed from the 207 bytes of themain data packet. Alternatively, if the inputted data correspond to thetraffic information data packet, the 20 bytes of RS parity place holdersare removed from the 207 bytes of the traffic information data packet inorder to perform the non-systematic RS-coding process.

As another embodiment of the E-VSB post-processor 504, if the inputteddata correspond to the 187-byte main data packet, the RS parity placeholder inserter 531 may perform a systematic RS-coding process so as toinsert a 20-byte RS parity at the end of the 187-byte main data.Accordingly, the RS parity place holder inserter 531 removes the last 20bytes of RS parity from the 207 bytes of the main data packet.Meanwhile, the RS encoder 505, the data interleaver 506, the backwardcompatibility processor 507, the trellis encoder 508, the framemultiplexer 509, the pilot inserter 510, the VSB modulator 511, and theRF up-converter 512 which are provided behind the E-VSB post-processor504 are identical to those shown in FIG. 10. Therefore, a detaileddescription of the same will be omitted for simplicity.

THIRD EMBODIMENT

FIG. 16 illustrates a block view showing a structure of a digitalbroadcast transmitting system according to a third embodiment of thepresent invention. Referring to FIG. 16, the digital broadcasttransmitting system includes an E-VSB pre-processor 601, a packetmultiplexer 602, a data randomizer 603, a RS encoder 604, a datainterleaver 605, an E-VSB post-processor 606, a backward compatibilityprocessor 607, a trellis encoder 608, a frame multiplexer 609, a pilotinserter 610, a VSB modulator 611, and a RF up-converter 612.

In the digital broadcast transmitting system according to the thirdembodiment of the present invention having the above describedstructure, the main data are inputted to the packet multiplexer 602. Onthe other hand, the traffic information data are inputted to the E-VSBpre-processor 601, which performs additional coding processes so as toenable the traffic information data to respond quickly with robustnessagainst noise and channel change. The structure and operation of eachcomponent of the E-VSB pre-processor 601 are identical to those of theE-VSB pre-processor 501 shown in FIG. 14. Therefore, a detaildescription of the same will be omitted for simplicity.

The traffic information data packet pre-processed by the E-VSBpre-processor 601 is inputted to the packet multiplexer 602 so as to bemultiplexed with the main data packet. The multiplexed data outputtedfrom the packet multiplexer 602 are data randomized by the datarandomizer 603 and, then, inputted to the RS encoder 604. The packetmultiplexer 602 multiplexes the main data packet and the trafficinformation data packet according to a pre-defined multiplexing rule. Atthis point, the main data packet and the traffic information data packetmay be multiplexed to have burst structures as shown in FIG. 10.Furthermore, if the traffic information data have been data randomizedby the E-VSB pre-processor 601, then the data randomizing process on thetraffic information data performed by the data randomizer 603 may beomitted.

The RS encoder 604 RS-codes the data being randomized from or bypassingthe data randomized 603, thereby adding a 20-byte RS parity andoutputting the processed data to the data interleaver 605. At thispoint, if the inputted data correspond to the main data packet, the RSencoder 604 performs a systematic RS-coding process identical to that ofthe conventional ATSC VSB system on the input data, thereby adding a20-byte RS parity at the end of the 187-byte data. Conversely, if theinputted data correspond to the traffic information data packet, the RSencoder 604 first decides 20 parity byte places and, then, performs anon-systematic RS-coding process on the decided parity byte places,thereby inserting the 20 bytes of non-systematic RS parity in thetraffic information data packet.

The non-systematic coding process is performed on the trafficinformation data packet because, when the value of the trafficinformation data is changed by the E-VSB post-processor 606, the processof which will be described in detail in a later process, the RS parityis required to be recalculated. And, at this point, the parity bytesshould be outputted later than the traffic information data bytes at theoutput end of the data interleaver 605. The data interleaver 605receives the data having parity added thereto by the RS encoder 604.Then, after performing an interleaving process, the data interleaver 605outputs the processed data to the E-VSB post-processor 606 and thebackward compatibility processor 607. Herein, the data interleaver 605receives the RS parity newly recalculated and outputted from thebackward compatibility processor 607, thereby outputting the received RSparity instead of non-systematic RS parity which is not yet outputted.

The E-VSB post-processor 606 performs additional coding processes insymbol units only on the traffic information data being outputted fromthe data interleaver 605. For example, if 1 byte has been expanded to 2bytes by inserting null bits between data bits from the E-VSBpre-processor 606, the E-VSB post-processor 606 ½-rate codes only thevalid data bit among the symbol configured of a null bit and a validdata bit and, then, outputs the processed data. On the other hand, if 1byte has been expanded to 4 bytes by inserting null bits between databits from the E-VSB pre-processor 601, the E-VSB post-processor 606¼-rate codes only the valid data bit among the symbol configured of 3null bits and 1 valid data bit and, then, outputs the processed data.

The main data or the RS parity being outputted from the data interleaver605 directly bypass (or bypasses) the E-VSB post-processor 606.Moreover, the known data and initialization data place holder alsodirectly bypass (or bypasses) the E-VSB post-process or 606. At thispoint, the known data place holder may be replaced with the known datagenerated from the E-VSB post-processor 606 and then outputted.Furthermore, the E-VSB post-processor 606 generates initialization dataso as to initialize the memory within the trellis encoder 608 to adecided status at the beginning of a known data sequence. Thereafter,the initialization data generated from the E-VSB post-processor 606 isoutputted instead of the initialization data place holder. Accordingly,the value of the memory within the trellis encoder 608 should bereceived from the E-VSB post-processor 606.

The backward compatibility processor 607 calculates the 20-bytenon-systematic RS parity corresponding to the traffic information datapacket configured on 187 data bytes and outputted from the E-VSBpost-processor 606. Subsequently, the calculated non-systematic RSparity is outputted to the data interleaver 605. The data interleaver605 receives the RS parity bytes calculated and outputted from thebackward compatibility processor 607 and, then, outputs the received RSparity bytes instead of the non-systematic RS parity. Herein, thebackward compatibility processor 607 performs a non-systematic RS-codingprocess because the E-VSB post-processor 606 changes the values of thetraffic information data and the initialization data place holder.Accordingly, when a decoding process is performed by the conventionalATSC VSB receiver, a decoding error may be prevented. In other words,this process is performed to provide backward compatibility to theconventional ATSC VSB receiver.

The data that are additionally coded and replaced by the E-VSBpost-processor 606 and that bypass the E-VSB post-processor 606 areinputted to the trellis encoder 608 so as to be trellis-encoded.Thereafter, the trellis-encoded data sequentially pass through the framemultiplexer 609, the pilot inserter 610, the VSB modulator 611, and theRF up-converter 612. Meanwhile, according to another embodiment of thepresent invention, initialization data, which are generated forinitializing a memory within the trellis encoder 608, are generated fromthe trellis encoder 608 instead of the E-VSB post-processor 606. In thiscase, the backward compatibility processor 607 receives a trafficinformation data packet from the E-VSB post-processor 606 in order tocalculate the parity value. Herein, the traffic information data packetincludes an initialization data place holder that is to be replaced bythe initialization data. Further, the backward compatibility processor607 receives the initialization data from the trellis encoder 608.Thereafter, the calculated non-systematic RS parity is outputted to thetrellis encoder 608. The remaining processes that may follow areidentical to those shown in FIG. 10. Therefore, a detailed descriptionof the same will be omitted for simplicity. Furthermore, the framemultiplexer 609, the pilot inserter 610, the VSB modulator 611, and theRF up-converter 612 are also identical to those shown in FIG. 10.Therefore, a detailed description of the same will also be omitted forsimplicity.

FIG. 17 illustrates a block view of a digital broadcast receiving systemaccording to an embodiment of the present invention. More specifically,FIG. 17 illustrates a block view showing an example of a digitalbroadcast receiving system that can receive traffic information databeing transmitted from a transmitting system and that demodulates andequalizes the received data, thereby recovering the processed data toits initial state. Referring to FIG. 17, the receiving system includes atuner 701, a demodulator 702, a demultiplexer 703, an audio decoder 704,a video decoder 705, a native TV application manager 706, a channelmanager 707, a channel map 708, a first memory 709, a data decoder 710,a second memory 711, a system manager 712, a data broadcastingapplication manager 713, and a GPS module 714. Herein, the first memory709 corresponds to a non-volatile memory (NVRAM) (or a flash memory).

The tuner 701 tunes a frequency of a particular channel through any oneof an antenna, a cable, and a satellite, thereby down-converting thetuned frequency to an intermediate frequency (IF) signal. Thereafter,the down-converted signal is outputted to the demodulator 702. At thispoint, the tuner 701 is controlled by the channel manager 707. Theresult and strength of the broadcast signal corresponding to the tunedchannel are reported to the channel manager 707. Herein, the data beingreceived through the frequency of a particular channel include the maindata, the enhanced data, and the table data which are used for decodingthe main data and enhanced data. In the example given in the presentinvention, traffic information data and a traffic information providingtable may be applied to the enhanced data.

The demodulator 702 performs VSB demodulation and channel equalizationprocesses on the signal outputted from the tuner 701. Then, afteridentifying the main data and the traffic information data from thesignal, the demodulator 702 outputs the data (or signal) by TS packetunits. The structure and operation of the demodulator 702 will bedescribed in detail in a later process. In the example of the presentinvention, only the traffic information data packet outputted from thedemodulator 702 is inputted to the demultiplexer 703. In other words,the main data packet may be inputted to another demultiplexer (notshown) that processes main data packets. Furthermore, the presentinvention may also be designed in a way that the demultiplexer 703 alsodemultiplexes the enhanced data packet as well as the main data packet.In the description of the present invention, the receiving andprocessing of traffic information data are described in detail. And, itshould be noted that a detailed description of the processing of maindata starting from the demultiplexer 703 may be omitted.

The demultiplexer 703 demultiplexes the traffic information messages andthe PSI/PSIP tables from the traffic information data packets beinginputted based upon the control of the data decoder 710. Thereafter, thedemultiplexed traffic information messages and PSI/PSIP tables areoutputted to the data decoder 710 in a section format. In an examplegiven in the present invention, a traffic information message carried bya payload within the TS packet is outputted in a DSM-CC section format.At this point, the demultiplexer 703 performs a section filteringprocess based upon the control of the data decoder 710 so as to deleteduplicate sections and to output only the non-duplicate sections to thedata decoder 710. Moreover, the demultiplexer 703 may output the sectionconfiguring a desired table (e.g., VCT) through a section filteringprocess to the data decoder 710. Herein, the VCT includes trafficinformation descriptors shown in FIG. 7. The traffic informationdescriptors may also be included in the PMT.

The section filtering method includes a method of initiating sectionfiltering after verifying the PID of a table defined by the MGT (e.g.,VCT), and, when the VCT has a fixed PID (i.e., a base PID), a method ofinitiating section filtering without verifying the MGT. At this point,the demultiplexer 703 performs section filtering by referring to thetable_id field, the version_number field, the section_number field, andso on. The data decoder 710 parses the DSM-CC section configuring thedemultiplexed traffic information message. Then, the data decoder 710decodes the traffic information message being a result of the parsingprocess and, then stores the traffic information message in a databaseof the second memory 711. The data decoder 710 groups a plurality ofsections having the same table identifiers (table_id) to configure andparse a table. Then, the data decoder 710 stores the system informationbeing the parsed result in the database of the second memory 711.

The second memory 711 is a table and data carousel database storingsystem information parsed from the tables and traffic informationmessages parsed from the DSM-CC section. Whether or not a table isconfigured of a single section or a plurality of sections can be knownby the table_id field, the section_number field, and thelast_section_number field within the table. For example, grouping onlythe TS packets having the PID of the VCT becomes a section. On the otherhand, grouping sections having table identifiers allocated to the VCTbecomes the VCT.

When parsing the VCT, information on the virtual channel to whichtraffic information is transmitted may be obtained. In addition,supplemental information associated with the traffic information messagedescribed, as shown in FIG. 7, in the traffic information descriptorsincluded in the VCT may also be obtained. More specifically, whenparsing the traffic information descriptors, application identificationinformation, service component identification information, serviceinformation (e.g., service name, service description, service logo,subscriber information, free text information, help information, etc.),and so on, of the traffic information message being transmitted to thecorresponding virtual channel can be obtained.

The application identification information, service componentidentification information, and service information of the trafficinformation message obtained as described above may either be stored inthe second memory 711 or outputted to the data broadcasting applicationmanager 713. Additionally, reference may be made to the applicationidentification information, service component identificationinformation, and service information for decoding the trafficinformation message. Alternatively, the application identificationinformation, service component identification information, and serviceinformation may also be used for preparing the operation of theapplication program for the traffic information message.

The data decoder 710 controls the demultiplexing of the systeminformation table corresponding to the table associated with channel andevent information. Thereafter, the data decoder 710 can transmit an A/VPID list to the channel manager 707. The channel manager 707 may referto the channel map 708 to send a request (or command) for receiving aninformation table associated with the system, and then the channelmanager 707 can receive the corresponding result. The channel manager707 may also control the channel tuning of the tuner 701. Furthermore,the channel manager 707 directly controls the demultiplexer 703 so as todirectly set up the A/V PID, thereby controlling the audio and videodecoders 704 and 705.

The audio and video decoders 704 and 705 may respectively decode andoutput the audio and video data demultiplexed from the main data packet,or respectively decode and output the audio and video data demultiplexedfrom the traffic information data packet. Meanwhile, according to theembodiment of the present invention, it is apparent that when trafficinformation data and also audio data and video data are included in theenhanced data, the audio data and video data demultiplexed by thedemultiplexer 703 may be respectively decoded by the audio decoder 704and the video decoder 705. For example, the audio decoder 704 may decodethe audio data by using an audio coding (AC)-3 decoding algorithm, andthe video decoder 705 may decode the video data by using an MPEG-2decoding algorithm.

Meanwhile, the native TV application manager 706 operates a nativeapplication program stored in the first memory 709, thereby performinggeneral functions such as channel switching. The native applicationprogram refers to a software that is being mounted upon shipping of thereceiving system. More specifically, when a user request is transmittedto the receiving system through a user interface (UI), the native TVapplication manager 706 the request onto the screen through a graphicuser interface (GUI), thereby responding to the user request. The userinterface receives the user request through an inputting device, such asa remote controller, a key pad, a jog dial, and a touch screen providedon the display screen. Thereafter, the user interface outputs thereceived user request to the native TV application manager 706, the databroadcasting application manager 713, and so on.

The native TV application manager 706 controls the channel manager 707,thereby controlling channel associated operations, such as managing thechannel map 708 and controlling the data decoder 710. In addition, thenative TV application manager 706 stores the GUI control of the generalreceiving system, the user request, and the status of the receivingsystem to the first memory 709, and also recovers the information storedin the first memory 709. The channel manager 707 controls the tuner 701and the data decoder 710, thereby managing the channel map 708 so as tobe able to respond to the channel request made by the user.

More specifically, the channel manager 707 sends a request to the datadecoder 710 so that the table associated with the channel, which is tobe tuned, can be parsed. Thereafter, the channel manager 707 receives areport on the parsing result of the corresponding table from the datadecoder 710. Then, depending upon the reported parsing result, thechannel manager 707 updates the channel map 708. The channel manager 707also sets up a PID to the demultiplexer 703 so as to demultiplex thetable associated with the traffic information message from the trafficinformation data. The system manager 712 controls booting of thereceiving system by turning on and off the power and, then, stores a ROMimage (including downloaded software images) to the first memory 709. Inother words, the first memory 709 stores operation programs, such asoperation system (OS) programs required for operating the receivingsystem, and application programs performing data service functions.

The application program is a program that processes the trafficinformation message stored in the second memory 711, thereby providingthe traffic information service to the user. If a data broadcasting datatype other than the traffic information data is stored in the secondmemory 711, the corresponding data are processed by the applicationprogram or another type of application program and, then, provided tothe user. The operation program and application program stored in thefirst memory 709 may be updated or corrected with a newly downloadedprogram. Furthermore, since the stored operation program and applicationprogram are not deleted even when the driving power supply is shut down,when the driving power is supplied, the program can be performed withouthaving to download a new program.

The application program for providing the traffic information serviceaccording to the present invention may be mounted in the first memory709 upon shipping of the receiving system, or stored later on in thefirst memory 709 after being downloaded. Also, the application programfor the traffic information service (i.e., traffic information providingapplication program) that is stored in the first memory 709 can bedeleted, updated, and corrected. Furthermore, the traffic informationproviding application program may also be downloaded along with thetraffic information data and executed each time the traffic informationdata are being received.

When a data service request is made through the user interface, the databroadcasting application manager 713 operates the correspondingapplication program stored in the first memory 709 so as to process therequested data, thereby providing the requested data service to theuser. And, in order to provide such data service, the data broadcastingapplication manager 713 supports the GUI. Herein, the data service isprovided in the form of text, voice, graphic, still image, motionpicture, and so on. The data broadcasting application manager 713 may beprovided with a platform for executing the application program stored inthe first memory 709. The platform may be, for example, a Java virtualmachine for executing a Java program.

Hereinafter, an example of providing traffic information service to theuser by having the data broadcasting application manager 713 execute thetraffic information providing application program stored in the firstmemory 709 and, then, process the traffic information message stored inthe second memory 711 will now be described in detail. The trafficinformation service according to the present invention is provided tothe users by a receiver having only one or none of an electronic map anda GPS mounted therein in the form of at least one of a text, a voice, agraphic, a still image, and a motion picture. If the GPS module 714 ismounted on the receiving system shown in FIG. 13, the GPS module 714receives satellite signals transmitted from a plurality of low earthorbit satellites so as to extract a current location information (i.e.,longitude, latitude, altitude), thereby outputting the extractedinformation to the data broadcasting application manager 713. At thispoint, it is assumed that the electronic map including information oneach link and node and the various graphic information are stored in astorage unit (or memory) other than the first memory 709 or the secondmemory 711.

By executing the traffic information providing application program, thedata broadcasting application manager 713 provides the trafficinformation service requested by the user based upon the currentlocation information acquired from the GPS module 714 and the trafficinformation message stored in the second memory 711. More specifically,based upon the request of the data broadcasting application manager 713,the traffic information message stored in the second memory 711 is readand inputted to the data broadcasting application manager 713. The databroadcasting application manager 713 analyses the traffic informationmessage read from the second memory 711, thereby extracting requiredinformation and/or control signals in accordance with the contents ofthe message. In the description of the present invention, it is assumedthat a request for a CTT service has been made by the user.

More specifically, the data broadcasting application manager 713extracts a message ID (i.e., a message component), a message generationtime, a message transmission time from the message management container102 of each traffic information message (or TPEG message), such that itdetermines whether the following container is equal to a CTT-statuscontainer on the basis of information of the message component. In thiscase, the message component information includes a message ID and aversion number. Also, the message component is requisite for allmessages and is adapted to manage the messages of the data broadcastingapplication manager 713.

If the following container is determined to be the CTT-status container104, the data broadcasting application manager 713 acquires (or obtains)information from the CTT status component of the CTT status container104. The data broadcasting application manager 713 acquires (or obtains)from the TPEG location container 106 a location informationcorresponding to a currently-transmitted traffic-carrying information.In this case, the location information may be location coordinates(latitude and longitude) of start and end points or a link of the startand end points according to location type information of the TPEGlocation container. In other words, the location information may be alink ID assigned to a road section (i.e., a road link). Whenevernecessary, a section may be specified as a link corresponding to thereceived information by referring to link- or node-information stored inthe second memory 711.

Provided that the location type information is a link ID, and thelocation information is text data (e.g., a road name) associated withthe link ID or a link, the present invention can specify a linkcorresponding to the received traffic-carrying status information byreferring to the corresponding link information. If the locationinformation acting as a link ID is a code for defining the link ID, thepresent invention can specify a link corresponding to the receivedtraffic-carrying status information by referring to the correspondinglink system stored in the second memory 711.

In the meantime, the data broadcasting application manager 713 readsdata of an electronic map from the second memory 711 on the basis ofcurrent location coordinates received from the GPS module 714, anddisplays the read electronic map data on a display screen. In this case,a specific graphic sign is displayed at a specific point correspondingto the current location. Under the above-mentioned situation, the databroadcasting application manager 713 receives average link speedinformation, such that the received information is displayed at specificlocation coordinates of a location container following the containerequipped with the average link speed information or at a linkcorresponding to a link ID. For the above-mentioned operation, differentcolors are assigned to individual average link speeds.

For example, if the road on the image is determined to a current road,the red color is indicative of 0 to 10 km per hour, the orange color isindicative of 10 to 20 km per hour, the green color is indicative of 20to 40 km per hour, and the blue color is indicative of at least 40 kmper hour. If the congestion change information has a specific value “1”or “2”, a character string (“Increase” or “Reduction”) or icon assignedto the specific value “1” or “2” may also be displayed on acorresponding link along with the congestion change information. If thecongestion change information has a specific value “0” or “3”, adisplayed status is not updated to a new status, such that a currentdisplayed status remains.

If a driver requests the display of the average speeds in the linksalong a driving route, the data broadcasting application manager 713 mayshow the average speed information corresponding to the links in thefront of the current driving route (or the links that belong to adriving route if the route has been predetermined) from among theaverage speed information received through the traffic informationmessage in the graphic. If a driver requests the display of travel timefor the links along a driving route, the data broadcasting applicationmanager 713 may show the travel time information corresponding to thelinks in the front of the current driving route (or the links thatbelong to a driving route if the route has been predetermined) fromamong the travel time information of the links received through thetraffic information message in the graphic.

For example, when average speed on a link is delivered with a resolutionfiner than 1.8 km/h (e.g., the implementations of FIGS. 4A through 4C),the average speed is displayed on a screen by the value included in thecorresponding field according to the predetermined resolution (1 km/h inFIG. 4B). Since the resolution is 1 km/h, difference in the averagespeed between two neighboring links is expressed in 1 km/h resolution(the area marked with ‘A’) or a multiple of the resolution. If averagespeed information expressed in another predetermined resolution (0.9km/h in FIG. 4A or 0.5 km/h and 1 km/h in FIG. 4C) is received, theaverage speed is obtained by multiplying the received information by thepredetermined resolution and difference in the average speed between twoneighboring links becomes a multiple of the resolution.

For example, when travel time for a link is provided along withinformation expressed in units of seconds (e.g., implementations ofFIGS. 5A through 5E), the information in units of seconds is alsodisplayed on the screen. If time information expressed only in units ofseconds is received, the received travel time for the link may beconverted to the format of units of minutes: units of seconds whenneeded.

The average speed or travel time for the link may be displayed on themap along a forward direction or at predetermined links.

In the implementations of FIGS. 4A and 4C, even though the average speedon a link may show a difference below 1 km/h, since the numeric value ofthe average speed is displayed separately on the screen, a driver, basedon the displayed information or on the travel time which is the lengthof the corresponding link divided by the average speed including thesame resolution, may choose a link to drive through.

According to one implementation for a simplified display, according tothe user's choice, average speed on a link may be displayed afterthrowing away the place values below decimal point. Similarly, as totravel time, only the element in minute may be kept and displayed, theelement in second being discarded.

Since the travel time for a link within a decoded status component(ID=01) may have information expressed in units of seconds when the databroadcasting application manager 713 delivers the travel, may delivertwo-byte information either by allocating one byte to each of minute andsecond or by converting the travel time to seconds. (When 16 bitinformation expressed in units of seconds is received, the informationis delivered as received.) Therefore, when the server also providestravel time for a link as the information expressed in units of seconds(e.g., the implementations of FIGS. 5A through 5E), the databroadcasting application manager 713 enables the navigation engine 5 toexpress the travel time for the link down to seconds; when an automatedpath finding function is provided, the data broadcasting applicationmanager 713 enables to find the shortest path by using the travel timefor the links including the resolution in second.

If the digital broadcast receiver, that is, the terminal in FIG. 17 isequipped with a voice output means, the terminal may output receivedaverage speed information or travel time for a specified link or linksincluded in a driving route in voice.

FIG. 18 illustrates a flow chart showing process steps of receiving andprocessing traffic information data according to an embodiment of thepresent invention. Referring to FIG. 18, a method of processing trafficinformation data according to the present invention will now bedescribed in detail. More specifically, when the power of the receivingsystem is turned on (S721), and when a channel selection or channelswitching is inputted (S722), a received channel signal is tuned to aphysical frequency so as to correspond to the selected or switchedchannel by using the channel map (S723). Herein, the channel selectionor channel switching is performed in accordance with a user command or asystem command.

At this point, the traffic information data having the trafficinformation message and the system information multiplexed therein maybe received through the channel frequency tuned as described above. Ifthe traffic information data are received (S724), the demultiplexer 703may demultiplex the traffic information message and system informationtables by using PID extraction and section filtering (S725). Among thesystem information, tables associated with channel information includethe VCT or the PAT/PMT. Herein, at least one of the PMT and VCT mayinclude the traffic information descriptor(s) according to the presentinvention. By parsing the system information table, information on thevirtual channel can be obtained, and whether an A/V element stream isbeing transmitted to the corresponding virtual channel and whether thetraffic information data are being transmitted can be known. If thetraffic information data are transmitted to the virtual channel, anapplication identifier, a service component identifier, and serviceinformation can be acquired by parsing the traffic informationdescriptor.

More specifically, information on the virtual channel is extracted byreferring to an element stream type (ES type) and PID within the systeminformation table (i.e., VCT and/or PAT/PMT) (S726). If the channelinformation extracted from the system information table indicates thatan A/V ES exists within the virtual channel (S727), an A/V PID of thecorresponding virtual channel in the channel map is set up (S728),thereby performing A/V demultiplexing and decoding (S729). Therefore,the user can view the broadcast program corresponding to the A/V (S730).Meanwhile, if it is indicated in Step 727 that an A/V ES does not existin the virtual channel, the present invention verifies when the trafficinformation data are being transmitted to the virtual channel (S731).

A plurality of methods for verifying whether the traffic informationdata have been transmitted to the virtual channel may be proposed. Forexample, verification can be performed by parsing the system informationtable, and verification can also be performed by using the PID withinthe TS packet. When assuming that the traffic information data have beentransmitted to the DSM-CC section, the existence (or presence) of thetraffic information data can be known by parsing the field value of anyone of the stream_type field within the PMT and the stream_type field ofthe service location descriptor within the VCT. In other words, if thestream_type field value is ‘0x95’, this indicates that the trafficinformation data have been transmitted to the corresponding virtualchannel. Therefore, if it is verified in Step 731 that the trafficinformation data are being transmitted to the virtual channel, alltraffic information having the DSM-CC data format that are beingtransmitted to the virtual channel are received (S732), therebyproviding the traffic information service desired (or requested) by theuser (S733).

If it is verified, in Step 731, that neither the A/V ES nor the trafficinformation data exist in the virtual channel, then the correspondingvirtual channel is determined to be an invalid channel. In this case,the system may display, for example, a message that no valid channel orsignal exists (S736). Thereafter, the process is returned to Step 724 inorder to newly receive a valid channel information table.

Meanwhile, the system verifies whether a request for changing (orswitching) the channel is made during the data service or while viewinga broadcast program (S734). If a change in channel has been requested,and if the request corresponds to changing the virtual channel, the databroadcasting process is reset, and the process is returned to Step 726in order to find a new set of virtual channel information. Further, ifthe request corresponds to changing the physical channel, the process isreturned to Step 723 so as to tune to the corresponding physicalchannel.

However, if there is no request for changing the channel, the systemverifies whether a channel information version has been upgraded (S735).If it is determined in Step 735 that the channel information version hasbeen upgraded, this indicates that the channel information has beenchanged (or modified) by the broadcast station. Therefore, the processis returned to Step 724 in order to receive a new channel informationtable. Conversely, if it is determined in Step 735 that the channelinformation has not been changed (or modified), then viewing of thebroadcast program may be resumed.

The demodulator (reference numeral 702 of FIG. 17) according to thepresent invention uses the known data information that is inputted to atraffic information data section and, then, transmitted by atransmitting system so as to perform process such as carrier wavesynchronization recovery, frame synchronization recovery, channelequalization, and so on. Thus, the receiving performance can beenhanced. FIG. 19 and FIG. 20 respectively illustrate detailed blockviews of the demodulator shown in FIG. 17.

Referring to FIG. 19, the demodulator includes a VSB demodulator 761, anequalizer 762, a known sequence (or data) detector 763, an E-VSB blockdecoder 764, an E-VSB data processor 765, and a main data processor 766.More specifically, an intermediate frequency (IF) signal of a channelfrequency tuned by the tuner 701 (shown in FIG. 17) is inputted to theVSB demodulator 761 and the known sequence detector 763. The VSBdemodulator 761 performs self gain control, carrier wave recovery, andtiming recovery processes on the inputted IF signal, thereby modifyingthe IF signal to a baseband signal. Then, the VSB demodulator 761outputs the newly created baseband signal to the equalizer 762 and theknown sequence detector 763. The equalizer 762 compensates thedistortion of the channel included in the demodulated signal and thenoutputs the error-compensated signal to the E-VSB block decoder 764.

At this point, the known sequence detector 763 detects the knownsequence location inserted by the transmitting end from the input/outputdata of the VSB demodulator 761 (i.e., the data prior to thedemodulation or the data after the modulation). Thereafter, the locationinformation along with the symbol sequence of the known data, which aregenerated from the detected location, is outputted to the VSBdemodulator 761 and the equalizer 762. Further, the known sequencedetector 763 outputs information related to the traffic information dataadditionally coded by the transmitting end and the main data that havenot been additionally coded to the E-VSB block decoder 764. Herein, theinformation allowing the traffic information data and the main data tobe differentiated (or identified) by the E-VSB block decoder 764 isoutputted to the E-VSB block decoder 764. Although the connection stateis not shown in FIG. 19, the information detected by the known sequencedetector 763 may be used throughout almost the entire receiving system.Herein, the detected information may also be used in the E-VSB datadeformatter 765-1 and in the RS frame decoder 765-2.

The VSB demodulator 761 uses the known data symbol sequence during thetiming and/or carrier recovery, thereby enhancing the demodulatingperformance. Similarly, the equalizer 762 uses the known data sequence,thereby enhancing the equalizing performance. Furthermore, the decodingresult of the E-VSB block decoder 764 may also be fed-back to theequalizer 762, thereby enhancing the equalizing performance. Meanwhile,when the data being inputted to the E-VSB block decoder 764, after beingequalized by the equalizer 762, correspond to the traffic informationdata being additionally coded and trellis-encoded by the transmittingend, the equalizer 762 performs an inverse process of the transmittingend by additionally decoding and trellis-decoding the inputted enhanceddata. On the other hand, when the data being inputted correspond to themain data being trellis-encoded only and not additionally coded, theequalizer 762 only performs trellis-decoding on the inputted main data.

The data group decoded by the E-VSB block decoder 764 is outputted tothe E-VSB data processor 765, and the main data packet is outputted tothe main data processor 766. More specifically, when the inputted datacorrespond to the main data, the E-VSB block decoder 764 performsViterbi-decoding on the input data so as to output a hard decision valueor to perform hard decision on a soft decision value and output thehard-decided result. Meanwhile, when the inputted data correspond to thetraffic information data, the E-VSB decoder 764 outputs a hard decisionvalue or a soft decision value on the inputted enhanced value.

More specifically, when the inputted data correspond to the trafficinformation data, the E-VSB block decoder 764 performs a decodingprocess on the data encoded by the E-VSB block processor and the trellisencoder of the transmitting system. At this point, the data outputtedfrom the RS frame encoder of the E-VSB pre-processor included in thetransmitting system may correspond to an external code, and the dataoutputted from each of the E-VSB block processor and the trellis encodermay correspond to an internal code. When decoding such concatenatedcodes, the decoder of the internal code should output a soft decisionvalue, so that the external coding performance can be enhanced.Therefore, the E-VSB block decoder 764 may output a hard decision valueon the traffic information data. However, it is more advantageous tooutput a soft decision value.

As an example of the present invention, the E-VSB data processor 765includes an E-VSB data deformatter 765-1, a RS frame decoder 765-2, andan E-VSB derandomizer 765-3. It would be efficient to apply thisstructure in the E-VSB pre-processor of the transmitting system (shownin FIG. 11) which includes an E-VSBG randomizer, a RS frame encoder, anE-VSB block processor, a group formatter, a data deinterleaver, and apacket formatter. The main data processor 766 includes a datadeinterleaver 766-1, a RS decoder 766-2, and a data derandomizer 766-3.

Herein, the data deinterleaver 766-1 the RS decoder 766-2, and the dataderandomizer 766-3 included in the main data processor 766 are blocksrequired for receiving the main data. Therefore, these blocks may not berequired in the structure of the receiving system that only receives thetraffic information data. The data deinterleaver 766-1 performs aninverse process of the data interleaver included in the transmittingend. More specifically, the data deinterleaver 766-1 deinterleaves themain data being outputted from the E-VSB block decoder 764 and outputsthe deinterleaved data to the RS decoder 766-2.

The RS decoder 766-2 performs systematic RS decoding on thedeinterleaved data and outputs the RS-decoded data to the dataderandomizer 766-3. The data derandomizer 766-3 receives the output ofthe RS decoder 766-2 and generates a pseudo random data byte identicalto that of the randomizer included in the transmitting system.Thereafter, the data derandomizer 766-3 performs a bitwise exclusive OR(XOR) operation on the generated pseudo random data byte, therebyinserting the MPEG synchronization bytes to the beginning of each packetso as to output the data in 188-byte main data packet units. At thispoint, the output of the data derandomizer 766-3 may be inputted to thedemultiplexer 703 shown in FIG. 17. Alternatively, the output of thedata derandomizer 766-3 may be inputted to a main data specificdemultiplexer (not shown), which demultiplexes the A/V data and channelinformation associated tables from the main data.

The data being outputted from the E-VSB block decoder 764 are inputtedto the E-VSB data deformatter 765-1 in a data group form. At this point,the E-VSB data deformatter 765-1 already knows the configuration of theinput data group. Accordingly, the E-VSB data deformatter 765-1 removesthe main data, the known data that have been inserted in the data group,the trellis initialization data, the MPEG header, and the RS parityadded by the RS encoder of the transmitting system that all wereinserted in the main data group. Thereafter, the E-VSB data deformatter765-1 outputs only the traffic information data to the RS frame decoder765-2. More specifically, the RS frame decoder 765-2 receives only thetraffic information data RS-coded and/or CRC-coded by the E-VSB datadeformatter 765-1.

The RS frame decoder 765-2 performs an inverse process of the RS frameencoder included in the transmitting system. Accordingly, the RS framedecoder 765-2 corrects the errors within the RS frame. Thereafter, theRS frame decoder 765-2 adds a 1-byte MPEG synchronization byte, whichwas removed during a RS frame coding process, to the error-correctedtraffic information data packet. Then, the processed data are outputtedto the E-VSB data derandomizer 766-3. At this point, if a rowpermutation process was performed on the traffic information data, aninverse row permutation process is also required. The E-VSB dataderandomizer 766-3 performs a derandomizing process, which correspondsto an inverse process of the E-VSB randomizer included in thetransmitting system, on the inputted traffic information data andoutputs the processed data. Thus, the transmitting system can receivethe transmitted traffic information data.

Meanwhile, if the E-VSB randomizer is positioned after the RS frameencoder in the structure of the E-VSB pre-processor included in thetransmitting system, the E-VSB data processor may include only the E-VSBdata deformatter and the RS frame decoder. In this case, the operationof the E-VSB data deformatter becomes partially different from that ofthe E-VSB data deformatter shown in FIG. 19. In other words, thedifference between the E-VSB data deformatter of FIG. 19 and theabove-described E-VSB data deformatter is that a derandomizing processis first performed on the traffic information data, and the RS framedecoding process is performed afterwards.

In this case, only the data derandomizing process may be performed, orthe data derandomizing process may be processed along with the null dataremoving process. This may differ depending upon the structure andoperation of the E-VSB pre-processor included in the transmittingsystem. More specifically, only the data derandomizing process may beperformed, or the data derandomizing process and the null data removingprocess may both be processed depending upon the positioning order ofthe E-VSB block processor and the group formatter, and whether thecoding process was performed only on the valid data by the E-VSB blockprocessor.

For example, if the E-VSB block processor is positioned before the groupformatter in the E-VSB pre-processor, the receiving system does notrequire the null data to be removed, since byte expansion has not beenperformed. In addition, even though a byte expansion process has beenperformed, if the E-VSB block processor has performed an additionalcoding process only on the valid data (e.g., if the coding process wasperformed at a coding rate of ½ or at a coding rate of ¼), the receivingsystem does not require the process of removing the null data.Conversely, if the E-VSB block processor is positioned after the groupformatter in the E-VSB pre-processor, the receiving system requires abyte expansion process to be performed. In this case, if the E-VSB blockprocessor has performed an additional coding process all data types(e.g., if the coding process was performed at a coding rate of ½ or at acoding rate of ¼), the receiving system requires the null data to beremoved.

However, if the removal of the expanded byte is required, the order ofthe byte removal process and the derandomizing process may varydepending upon the structure of the transmitting system. Morespecifically, if the byte expansion is performed after the randomizingprocess in the transmitting system, then the byte removal process isfirst performed before performing the derandomizing process in thereceiving system. Conversely, if the order of the process is changed inthe transmitting system, the order of the respective processes in thereceiving system is also changed.

When performing the derandomizing process, if the RS frame decoderrequires a soft decision in a later process, and if, therefore, theE-VSB block decoder receives a soft decision value it is difficult toperform an XOR operation between the soft decision and the pseudo randombit, which is used for the derandomizing process. Accordingly, when anXOR operation is performed between the pseudo random bit and the softdecision value of the traffic information data bit, and when the pseudorandom bit is equal to ‘1’, the E-VSB data deformatter changes the codeof the soft decision value and then outputs the changed code. On theother hand, if the pseudo random bit is equal to ‘0’, the E-VSB datadeformatter outputs the soft decision value without any change in thecode. Thus, the state of the soft decision may be maintained andtransmitted to the RS frame decoder.

If the pseudo random bit is equal to ‘1’ as described above, the code ofthe soft decision value is changed because, when an XOR operation isperformed between the pseudo random bit and the input data in therandomizer of the transmitter, and when the pseudo random bit is equalto ‘1’, the code of the output data bit becomes the opposite of theinput data (i.e., 0 XOR 1=1 and 1 XOR 0=0). More specifically, if thepseudo random bit generated from the E-VSB packet deformatter is equalto ‘1’, and when an XOR operation is performed on the hard decisionvalue of the traffic information data bit, the XOR-operated valuebecomes the opposite value of the hard decision value. Therefore, whenthe soft decision value is outputted, a code opposite to that of thesoft decision value is outputted.

Accordingly, the RS frame decoder performs an inverse process of the RSframe encoder included in the transmitting system. Therefore, the RSframe decoder corrects the errors within the RS frame. Subsequently, theRS frame decoder adds a 1-byte MPEG synchronization byte, which wasremoved during a RS frame coding process, to the error-corrected trafficinformation data packet. Thus, the initial traffic information datatransmitted by the transmitting system can be obtained.

FIG. 20 illustrates a detailed block view of the demodulator accordingto a second embodiment of the present invention. Referring to FIG. 20,the demodulator includes a VSB demodulator. 781, an equalizer 782, aknown sequence (or data) detector 783, a Viterbi decoder 784, a datadeinterleaver 785, a RS decoder 786, a data derandomizer 787, and anE-VSB data processor 788. Herein, the E-VSB data processor 788 includesa main data packet remover 788-1, an E-VSB packet deformatter 788-2, andan E-VSB data processor 788-3. It would be efficient to apply thedemodulator shown in FIG. 20 to the transmitting system having thestructure shown in FIG. 16. Furthermore, the VSB demodulator 781, theequalizer 782, and the known sequence detector 783 are identical tothose shown in FIG. 19. Therefore, since reference can be made for thestructure of the same components, a detailed description of the samewill be omitted for simplicity.

The Viterbi decoder 784 Viterbi-decodes the data outputted from theequalizer 782 and converts the Viterbi-decoded data to bytes.Thereafter, the converted data are outputted to the data deinterleaver785. The data deinterleaver 785 performs an inverse process of the datainterleaver of the transmitting system and outputs the deinterleaveddata to the RS decoder 786. If the received data packet is the main datapacket, the RS decoder 786 RS-decodes the received main data packet.Alternatively, if the received data packet is the traffic informationdata packet, the RS decoder 786 removes the non-systematic RS paritybytes and outputs the processed data to the data derandomizer 787.

The data derandomizer 787 performs an inverse process of the randomizerof the transmitting system on the output of the RS decoder 786.Thereafter, the data derandomizer 787 inserts the MPEG synchronizationbyte in the beginning of each packet, thereby outputting the data in188-byte packet units. The output of the data derandomizer 787 issimultaneously outputted to the demultiplexer 703 (shown in FIG. 17) orthe main data specific demultiplexer (not shown) and outputted to themain data packet remover 788-1 of the E-VSB data processor 788.

The main data packet remover 788-1 removes the 188-byte main data packetfrom the data outputted from the data derandomizer 787 and outputs theprocessed data to the E-VSB packet deformatter 788-2. The E-VSB packetdeformatter 788-2 removes the 4-byte MPEG header, known data, andtrellis initialization data from the 188-byte data packet. Then, theE-VSB packet deformatter 788-2 outputs only the traffic information datato the E-VSB data processor 788-3. At this point, the E-VSB packetdeformatter 788-2 may or may not remove the null data.

More specifically, when the E-VSB post-processor of the transmittingsystem shown in FIG. 16 performs additional coding on the trafficinformation data, and, accordingly, when the coding is performed only onthe valid traffic information data, the removing of the null data is notrequired. Conversely, however, if the additional coding process isperformed on all byte-expanded traffic information data, the null datamust be removed. The E-VSB data processor 788-3 performs an inverseprocess of the E-VSB pre-processor included in the transmitting systemon the output of the E-VSB packet deformatter 788-2. Thus, the trafficinformation data initially transmitted from the transmitting system maybe obtained.

As described above, the digital broadcast transmitting/receiving systemand the method for processing data are advantageous in that whenreceiving traffic information data through a channel, the data arerobust against error and are compatible with the conventional VSBreceiver. Furthermore, data can be received more efficiently withouterror even in channels having severe noise and ghost effect.

In addition, by performing additional error correction coding and errordetection coding processes on the traffic information data andtransmitting the processed data, robustness is provided to the trafficinformation data, thereby allowing the data to respond appropriately tothe changes in the channel environment. Furthermore, by using linkidentifiers for providing the traffic information data, the transmissioncapacity may be minimized. And, by warning in advance the information onheavy congested traffic status, the amount of traffic may be adequatelydispersed, thereby allowing the roads to be circulated efficiently. Thepresent invention having the above-described advantages ma be moreefficiently used when applied in mobile and portable receiver whichrequires a greater degree of robustness against noise and ghost effect.

It will be apparent to those skilled in the art that variousmodifications and variations can be made in the present inventionwithout departing from the spirit or scope of the inventions. Thus, itis intended that the present invention covers the modifications andvariations of this invention provided they come within the scope of theappended claims and their equivalents.

1. A digital broadcast transmitter, comprising: a pre-processorconfigured to pre-process traffic information data, wherein the trafficinformation data is included in a data group, the traffic informationdata generated from forming the data group, the data group includingknown data in advance known to the receiver and a digital broadcasttransmitter which is inserted continuously and periodically and trellisinitialization data located in front of the known data; a multiplexerconfigured to multiplex the traffic information data with one or moremain audio and video, AV, data; a trellis encoder configured to have atleast one memory and trellis-encode the multiplexed data, the at leastone memory being initialized by the trellis initialization data whendata outputted from the multiplexer correspond to a beginning of asequence of the known data; and a data transmission unit configured toinsert synchronization data into the trellis-encoded data, modulate thetrellis-encoded data having the synchronization data, and transmit themodulated data, wherein the traffic information data include statusinformation, which includes at least one of information on an averagespeed of a traffic route and route travel time, and location informationassociated with the status information.
 2. The digital broadcasttransmitter of claim 1, wherein the information on the average speed ofthe traffic route is indicated in a speed unit less than 1.8 km/h, andwherein the information on the route travel time is indicated in a timeunit lower than a minute-unit.
 3. The digital broadcast transmitter ofclaim 2, wherein the status information further comprises an identifierindicating that information on the average speed of the traffic route isincluded, and an identifier indicating that information on the routetravel time is included.
 4. The digital broadcast transmitter of claim1, further comprising: an encoder configured to add first parity data tothe multiplexed data; a data interleaver configured to interleave themultiplexed data having the parity data; and a compatible processorconfigured to calculate second parity data from the interleaved data andthe initialization data and replace the first parity data within theinterleaved data with the second parity data.
 5. The digital broadcasttransmitter of claim 1, wherein the pre-processor comprises: arandomizer configured to randomize the traffic information data; a firstencoder configured to generate data frames including the randomized dataand encode each data frame for at least one or error correction anderror detection; a second encoder configured to encode only trafficinformation data included in the data encoded by the first encoder witha coding rate of G/H, wherein G and H are positive integers and G isless than H; a group formatter configured to insert the data encoded bythe second encoder and the known data into a data group having aplurality of regions; a data deinterleaver configured to deinterleavethe data included in the data group; and a packet formatter configuredto add header data to the deinterleaved data to generate data packets.6. The digital broadcast transmitter of claim 5, wherein the groupformatter further inserts header location holders, main AV data holders,and parity data holders into the data group.
 7. The digital broadcasttransmitter of claim 5, wherein the group formatter further insertsinitialization data location holders into the data group.
 8. A digitalbroadcast transmitter, comprising: a pre-processor configured topre-process traffic information data, wherein the traffic informationdata is included in a data group, the traffic information data generatedfrom forming the data group, the data group including known data inadvance known to the receiver and a digital broadcast transmitter whichis inserted continuously and periodically and trellis initializationdata located in front of the known data; a multiplexer configured tomultiplex the traffic information data with one or more main audio andvideo, AV, data; a post-processor configured to pro-process themultiplexed data by encoding only traffic information data included inthe multiplexed data with a coding rate of G/H, wherein G and H arepositive integers and G is less than H; a data encoding and interleavingunit configured to add first parity data into the post-processed dataand interleave the post-processed data having the first parity data; atrellis encoder configured to have at least one memory andtrellis-encode the interleaved data, the at least one memory beinginitialized by initialization data when data outputted from the dataencoding and interleaving unit correspond to a beginning of a sequenceof known data; and a data transmission unit configured to insertsynchronization data into the trellis-encoded data, modulate thetrellis-encoded data having the synchronization data, and transmit themodulated data, wherein the traffic information data include statusinformation, which includes at least one of information on an averagespeed of a traffic route and route travel time, and location informationassociated with the status information.
 9. The digital broadcasttransmitter of claim 8, wherein the information on the average speed ofthe traffic route is indicated in a speed unit less than 1.8 km/h, andwherein the information on the route travel time is indicated in a timeunit lower than a minute-unit.
 10. The digital broadcast transmitter ofclaim 8, further comprising a compatible processor calculating secondparity data from the interleaved data and the initialization data andreplacing the first parity data within the interleaved data with thesecond parity data.
 11. The digital broadcast transmitter of claim 8,wherein the pre-processor comprises: a first encoder configured togenerate data frames including the traffic information data and encodeeach data frame for at least one of error correction and errordetection; a randomizer configured to randomize the traffic informationdata encoded by the first encoder; a group formatter configured toinsert the randomized data and the known data into a data group having aplurality of regions; a data deinterleaver configured to deinterleavethe data included in the data group; and a packet formatter configuredto add header data to the deinterleaved data to generate data packets.12. The digital broadcast transmitter of claim 8, wherein thepost-processor comprises: a location holder inserter configured toinsert parity location holders to the data multiplexed by themultiplexer; a data interleaver configured to interleave the data havingthe parity location holders; a block processor configured to encode onlytraffic information data included in the data interleaved by the datainterleaver with a coding rate of G/H, wherein G and E are positiveintegers and G is less than H; a data deinterleaver configured todeinterleave the data encoded by the block processor; and a paritylocation holder remover configured to remove the parity location holdersincluded in the deinterleaved data.
 13. A digital broadcast transmitter,comprising: a pre-processor configured to pre-process trafficinformation data, wherein the traffic information data is included in adata group, the traffic information data generated from forming the datagroup, the data group including known data in advance known to thereceiver and a digital broadcast transmitter which is insertedcontinuously and periodically and trellis initialization data located infront of the known data; a multiplexer configured to multiplex thetraffic information data with one or more main audio and video, AV,data-packets; a data encoding and interleaving unit configured to addfirst parity data into the multiplexed data and interleaving themultiplexed data having the parity data; a post-processor configured topost-process the interleaved data by coding only traffic informationdata included in the interleaved data with a coding rate of G/H, whereinG and H are positive integers and G is less than H; a trellis encoderconfigured to have at least one memory and trellis-encode thepost-processed data, the at least one memory being initialized by thetrellis initialization data when data outputted from the post-processorcorrespond to a beginning of a sequence of the known data; and a datatransmission unit configured to insert synchronization data into thetrellis-encoded data, modulate the trellis-encoded data having thesynchronization data, and transmit the modulated data, wherein thetraffic information data includes status information, which includes atleast one of information on an average speed of a traffic route androute travel time, and location information associated with the statusinformation.
 14. The digital broadcast transmitter of claim 13, furthercomprising a compatible processor calculating second parity data fromthe post-processed data and the initialization data and replacing thefirst parity data within the post-processed data with the second paritydata.
 15. A method of processing traffic information data in a digitalbroadcast receiver, the method comprising: receiving traffic informationdata and system information, the traffic information data generated fromforming a data group, the data group including known data in advanceknown to the receiver and a digital broadcast transmitter which isinserted continuously and periodically and trellis initialization datalocated in front of the known data, and trellis encoding the known databased on the trellis initialization data in a transmitter;demultiplexing the traffic information data and the system information;decoding the traffic information data using the system information,thereby extracting information on at least one of an average speed of atraffic route and route travel time, and location information associatedwith the status information; and providing a traffic information serviceto a user using the extracted information.
 16. The method of claim 15,further comprising detecting service information associated with thetraffic information data from at least one of a program map table and avirtual channel table which includes the system information.
 17. Adigital broadcast receiver, comprising: a demodulator configured todemodulate traffic information data information, the traffic informationdata generated from forming a data group, the data group including knowndata in advance known to the receiver and a digital broadcasttransmitter which is inserted continuously and periodically and trellisinitialization data located in front of the known data, and trellisencoding the known data based on the trellis initialization data in atransmitter; a data decoding unit configured to decode the demodulatedtraffic information data; a data storage configured to store the decodedtraffic information data; and an application manager configured toprovide a traffic information service to a user using the stored trafficinformation data by extracting information on at least one of an averagespeed of a traffic route and route travel time, and location informationassociated with the status information, wherein the demodulatorcomprises: an equalizer configured to channel-equalize the trafficinformation data based on the known data; a block decoder configured toperform soft decision decoding on the channel-equalized trafficinformation data; and a reed solomon frame decoder configured to performan inverse process of a reed solomon frame encoder included in thetransmitter.
 18. A digital broadcast receiver, comprising: a tunerconfigured to receive traffic information data, the traffic informationdata generated from forming a data group, the data group including knowndata in advance known to the receiver and a digital broadcasttransmitter which is inserted continuously and periodically and trellisinitialization data located in front of the known data, and trellisencoding the known data based on the trellis initialization data in thetransmitter; a demodulator configured to perform demodulating on thetraffic information data based on the known data; and a decoderconfigured to perform decoding on the demodulated traffic informationdata.
 19. The digital broadcast receiver of claim 18, wherein thetraffic information data include status information, which includes atleast one of information on an average speed of a traffic route androute travel time, and location information associated with the statusinformation.
 20. A digital broadcast receiver, comprising: a tunerconfigured to receive enhanced data, the enhanced data generated fromforming a data group, the data group including known data in advanceknown to the receiver and a digital broadcast transmitter which isinserted continuously and periodically and trellis initialization datalocated in front of the known data, and trellis encoding the known databased on the trellis initialization data in the transmitter; ademodulator configured to perform demodulating on the enhanced databased on the known data; and a decoder configured to perform decoding onthe demodulated enhanced data.
 21. The digital broadcast receiver ofclaim 20, wherein the data group is divided into at least two areas, onearea of them having main data and the enhanced data able to be coded ata first code rate, and another area of them having the enhanced dataable to be coded at a second code rate lower than the first code rate.22. A method of processing digital broadcast data in a digital broadcastreceiver, comprising: receiving traffic information data, the trafficinformation data generated from forming a data group, the data groupincluding known data in advance known to the receiver and a digitalbroadcast transmitter which is inserted continuously and periodicallyand trellis initialization data located in front of the known data, andtrellis encoding the known data based on the trellis initialization datain the transmitter; performing demodulating on the traffic informationdata based on the known data; and performing decoding on the demodulatedtraffic information data.
 23. The method of claim 22, wherein thetraffic information data include status information, which includes atleast one of information on an average speed of a traffic route androute travel time, and location information associated with the statusinformation.
 24. A method of processing digital broadcast data in adigital broadcast receiver, comprising: receiving enhanced data, theenhanced data generated from forming a data group, the data groupincluding known data in advance known to the receiver and a digitalbroadcast transmitter which is inserted continuously and periodicallyand trellis initialization data located in front of the known data, andtrellis encoding the known data based on the trellis initialization datain the transmitter; performing demodulating on the enhanced data basedon the known data; and performing decoding on the demodulated enhanceddata.
 25. The method of claim 24, wherein the data group is divided intoat least two areas, one area of them having main data and the enhanceddata able to be coded at a first code rate, and another area of themhaving the enhanced data able to be coded at a second code rate lowerthan the first code rate.